Iphone
shpora.me - незаменимый помощник для студентов и школьников, который позволяет быстро создавать и получать доступ к шпаргалкам или другим заметкам с любых устройств. В любое время. Абсолютно бесплатно. Зарегистрироватся | Войти

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

Екзамен ПП -mike

Лекція 1 Базові складові Grid і ресурси

 

1.1 Напрями розвитку технології 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 Computing Grid), який, по суті, і є його технологічною базою.

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

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

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

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

 

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

 

Прогрес в області розробки нових обчислювальних пристроїв і мережевих технологій вражає. Тільки за останніх 15 років тактова частота персональних машин зросла з 10 Мгц до 5ГГц (500 разів), а пропускна спроможність мереж з 10 Мбіт/с до 100 Гбіт/с (10000 разів).

Але не за горами деякі принципові обмеження, наприклад, постійна часу поляризації діелектрика рівна 10 – 13сек, що встановлює верхню межу на тактову частоту будь – яких операцій на рівні ~1013 Гц. (Тгц).

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

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

У якійсь мірі техніка 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.

Для забезпечення 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 сукупність людей і організацій, що вирішують спільно те або інше загальне завдання і що надають один одному свої ресурси, називається віртуальною організацією. Наприклад, віртуальною організацією може бути сукупність всіх людей, що беруть участь в якій-небудь науковій колаборації. Віртуальні організації можуть розрізнятися за складом, масштабом, часом існування, родом діяльності, цілями, відносинами між учасниками (довірені/не довірені особи) і так далі. Склад віртуальних організацій може динамічно мінятися.

 

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

 

У останні декілька років технологія Grid еволюціонувала від ретельно конфігурованої інфраструктури, яка підтримувала виконання обмеженого числа додатків категорії Grant Challenge на високопродуктивній апаратурі, до динамічного середовища, розвиток якого направляє міжнародне співтовариство. У міру становлення технологіїGrid реальністю до процесу її розвитку все більш залучається індустрія. Участь комерційних організацій прискорює розробку надійного програмного забезпечення, що підтримує середовища Grid за межами академічних лабораторій. У свою чергу, це впливає як на архітектуру Grid, так і на пов'язані з нею  протоколи і стандарти. Пристосування до архітектури Grid технології Web-сервисів принесло істотну користь та привело до появи дещо фрагментованого середовища розробки. Розробники програмного забезпечення і Grid-сервісів добиваються відповідності угодам і стандартам, широко поширеним в їх співтоваристві. Проте по різних політичних і технічних причинах є декілька точок зору, що змагаються, щодо того, як слід реалізовувати архітектуру, і на які стандарти потрібно спиратися. Це суперництво гальмує розробників програмного забезпечення Grid, оскільки вони не упевнені, що майбутні стандарти включатимуть ті, що використовуються сьогодні. Основною організацією по стандартизації Grid є GlobalGrid 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. У березні 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 (визначається базовий 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 є GridSecurity 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 інтегруватися з традиційною інфраструктурою корпоративної безпеки.

 

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

 

Open Grid Services Architecture (OGSA) направлена на стандартизацію адресації (для сумісності), за допомогою визначення основи структури додатку GRID. По суті стандарт OGSA визначає сервіси GRID, їх можливості і те, на яких технологіях вони засновані. Проте, OGSA не розрізняє особливостей технічної сторони специфікації; метою є визначення – що є системою GRID. OGSA називають архітектурою, оскільки вона направлена на побудову і установку інтерфейсів, з яких можуть бути побудовані, системи, засновані на відкритих стандартах WSDL.

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

Тип порту

Операція

Опис

GridService

FindServiceData

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

SetTermination Time

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

Destroy

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

Notification – Source

SubscribeTo –NotificationTopic

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

Notification – Sink

Deliver Notification

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

Registry

RegisterServiceUnregisterService

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

Factory

CreateService

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

Handle Map

FindByHandle

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

 

 

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

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

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

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

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

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

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

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

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

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

Хоча сама технологія GRID не прив'язана до певних ресурсів, найчастіше реалізації GRID – систем забезпечують роботу з наступними типами ресурсів:

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

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

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

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

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

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

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

 

Підпис: Рівні протоколів ГрідПідпис: Рівні протоколів Інтернет

Рисунок 1.1 – Рівні архітектури протоколів Grid і їх відповідність рівням архітектури протоколів Інтернет

 

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

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

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

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

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

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

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

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

 

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

 

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

 

Базовий рівень (Fabric Layer) архітектури GRID описує служби, що безпосередньо працюють з ресурсами. Ресурс є одним з основних понять архітектури GRID. Ресурси можуть бути вельми різноманітними, проте, як вже згадувалося раніше, можна виділити декілька основних типів (рисунок 1.2):

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

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

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

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

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

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

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

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

 

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

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

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

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

Протоколи рівня зв'язку повинні забезпечувати надійний транспорт і маршрутизацію повідомлень, а також привласнення імен об'єктам мережі. Не дивлячись на існуючі альтернативи, зараз протоколи рівня зв'язку в GRID – системах припускають використання тільки стека протоколів TCP/IP, зокрема: на мережевому рівні – IP і ICMP, транспортному рівні – TCP, UDP, на прикладному рівні – HTTP, FTP, DNS, RSVP. Враховуючи бурхливий розвиток мережевих технологій, в майбутньому рівень зв'язку, можливо, залежатиме і від інших протоколів.

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

 

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

 

1.4.6 Стандарти, що використовуються для побудови архітектури GRID

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

·     Комунікації «програма – програма» (SOAP, WSDL, і UDDI);.

·     Сумісне використання даних (мова XML).

·     Передача повідомлень(SOAP, WS – Addressing, MTOM (для додатків));

·     Надійна передача повідомлень (WS – Reliable Messaging);

·     Управління робочим процесом (WS – Management);

·     Управління транзакціями(WS – Coordination, WS – AtomicTransaction, WS – Business – Activity);

·     Розподіл ресурсів (WS – RF або система ресурсних Web – сервісів);

·     Забезпечення безпеки (WS – Security, WS – SecureConversation, WS – Trust, WS – Federation, Система безпечних зв'язків Kerberos для Web – сервісів;

·     Обробка метаданих(WSDL, UDDI, WS – Policy).

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

·     Верхній рівень управління бізнес – процесом (інженерна мова бізнес – процесу для Web сервісів – BPEL4WS)

·     Події, що запускають бізнес – процес (WS – Notification).

Горизонтальна і вертикальна інфраструктура програмного забезпечення, яка необхідна для забезпечення безпеки, пошти, обміну повідомленнями, робочого потоку,колаборації, обмінів програма – програма, а також середовища сумісного використання даних може бути знайдена в інфраструктурних пропозиціях таких компаній як IBM (WebSphere), Microsoft (.NET), BEA (WebLogic) і Sun (ONE). Web – сервіси і XML реалізації містяться в пропозиціях інших постачальників.

1.4.6.1 Сервіс-орієнтована архітектура

Фундаментальною концепцією OGSA є те, що сервісна архітектура складається з компонентів служб GRID, які працюють як спеціальні Web – сервіси, що надають ряд інтерфейсів, що відповідають спеціальним вимогам. SOA визначає, як взаємодіють два обчислювальні об'єкти, для того, щоб один об'єкт дав можливість другому виконати визначену роботу на користь першого. Ця робота співвідноситься з сервісом, а дії сервісу визначаються мовою описів. Кожна взаємодія самостійна і практично не залежить від іншого. Бізнес додатки створюються для автоматизації різних бизнес – процесів, але часто без здійснення в них можливості адаптуватися до потреб, що змінюються; доопрацювання бізнес процесів в даному середовищі, достатньо трудомістке завдання. Все тому, що бізнес додатки традиційно створюються як одиничні, монолітні, такі, що включають всі інструменти. Тому будь – які зміни в них достатньо дорогі і займають багато часу. У середовищі SOA, додатки створюються у вигляді набору сервісів, кожен з яких має свої завдання і властивості. У міру зміни потреб, деякі сервіси можуть додаватися, деякі видалятися або доопрацьовуватися.

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

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

·     Сервіс є здійснимим, він описується на XML і доступі до нього може бути здійснений за допомогою XML – повідомлень.

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

·     Він не залежить від платформи або мови.

Web – сервіс є системою ПЗ, URL якого ідентифікується, а інтерфейси і зв'язки визначені і описані за допомогою XML. Він може бути виявлений іншими системами ПЗ. Ці системи, у свою чергу, можуть взаємодіяти з Web – сервісом, використовуючи XML повідомлення, що передаються за допомогою Інтернет протоколів. Мова описів Web–сервісів (WSDL) фактично є, заснованим на XML, стандартом для опису Web–сервісів. Простий протокол доступу до об'єктів (SOAP) є, заснованим на XML, стандартним мережевим протоколом для обміну повідомленнями між Web – сервісами (описи W3C).

1.4.6.2 Мова описів Web – сервісів

WSDL документ (мова описів Web – сервісів) визначає Web – сервіс, використовуючи приведені нижче основні елементи:

 

Таблиця 1.2 – Деякі позначення елементів у мові описів Web – сервісів

Елемент

Визначає

<portType>

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

<Message>

Повідомлення, використовувані в Web – сервісе. Абстрактне визначення передаваних даних

<Types>

Типи даних, використовувані в Web – сервісе. Надає інформацію про будь – які складні типи даних, вживаних в документах WSDL. У разі використання простих типів даних цей елемент не потрібний.

<Binding>

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

<Port>

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

<Service>

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

 

 

WSDL документ містить описи елементів, що складаються з блоків types, message, portType, binding, і service elements, що описане в таблиці вище. Основна структура документа WSDL виглядає таким чином:

<definitions>

<types>

опис типів. . .

</types>

<message>

опис повідомлень . . .

</message>

<portType>

опис порту . . .

</portType>

<binding>

опис з'єднання . . .

</binding>

</definitions>

1.4.6.3 Web Services Inspection Language

Web Services Inspection Language (WSIL) – простий механізм виявлення Web – сервісів. WSIL – формат XML документа, створений для полегшення збору і виявленняWeb – сервісів. Створений IBM і Microsoft і виданий в кінці 2001 року, WSIL є привабливим за рахунок своєї простоти, в порівнянні з UDDI, він простий і краще «піднімає» існуючі Web – сервіси. Модель WSIL децентрализована і «піднімає» існуючі Web – сервіси прямо на місці.

1.4.6.4 Universal Description, Discovery, and Integration

Universal Description, Discovery, and Integration (UDDI) – стандартний протокол опису Web – сервісів і протокол їх пошуку. Реєстр (UDDI) може містити метадані для будь – яких видів сервісів, разом з варіантами «якнайкращої практики», вже визначеними для сервісів, описаних за допомогою WSDL. За рахунок розбиття Web – сервісів на групи, що взаємодіють з категоріями і бізнес процесами, UDDI здатний ефективно шукати Web – сервіси. Специфікація UDDI визначає ієрархічну схему XML, що забезпечує модель для анонсування, перевірки і виклику інформації про Web – сервіси. Вибір ліг на XML, оскільки його формат представлення даних не залежить від платформи і відображає ієрархічні взаємозв'язки. У UDDI використовуються технології, засновані на загальних інтернет протоколах TCP/IP, HTTP, XML і SOAP. Існує 2 види UDDI реєстрів: публічні реєстри UDDI – службовці точками збору різних бізнесів, для повідомлення про їх сервіси, приватні реєстри UDDI, які роблять те ж саме але для організацій.

UDDI регістр містить наступні структурні типи даних:

·     businessEntity. XML – элемент верхнього рівня в бізнес запису UDDI. businessEntity збирає дані по запиту інформації об бізнес обслуговуванні, категорії продукту або виробництва, географічному положенні, а також контактну інформацію. Він підтримує пошук по організаціях, продуктах і географічному положенні.

·     businessService. Логічне продовження структури даних businessEntity і родоначальник структури bindingTemplate. businessService містить описову інформацію бізнес послуг з груп споріднених технічних послуг, включаючи ім'я групи, коротку інформацію про групу, опис технічної послуги, інформацію про категорію.

·     bindingTemplate. Логічне продовження структури businessService. bindingTemplate містить дані, що відносяться до додатків, які необхідно запустити або пов'язати з Web – сервісом. Ця інформація містить URL Web – сервіса, посилання на специфікації інтерфейсу і ін.

·     tModel. Містить описи специфікації Web – сервісів або систематики, які формують основу для технічних ідентифікаторів. Роль tModel полягає в наданні технічних специфікацій Web – сервісів, що дозволяє полегшити пошук Web – сервісів, сумісних з певною технічною специфікацією. Користувачі Web – сервісів можуть легко визначити інші сумісні Web – сервіси, грунтуючись на описі специфікацій в структурі tModel. Наприклад, для того, щоб послати биснес – партнеру RFP, запрошуюча служба повинна знати не тільки URL/местоположение служби, але і в якому форматі повинен бути посланий RFP, які протоколи використовувати, врахувати вимоги безпеки, яку форму відгуку має на увазі відсилання RFP.

1.4.6.5 Протокол SOAP (Simple Object Access Protocol)

SOAP – простий, заснований на XML, протокол, для обміну інформацією в децентралізованому, розподіленому середовищі. SOAP підтримує різні стилі обміну інформацією, включаючи:

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

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

SOAP характеризується:

·     Протокольною незалежністю.

·     Мовною незалежністю.

·     Незалежністю від ОС і платформи.

·     Підтримкою SOAP XML – повідомлень взаємодіючих частин (використовуючи багатоскладну структуру MIME).

Повідомлення SOAP складається з (1) SOAP конверта, який містить дві структури даних, (2) SOAP – заголовка і тіла SOAP і (3) інформації про імена, службовців для їх опису. Заголовок є необов'язковою частиною, він передає інформацію про запит, визначений в тілі SOAP. Наприклад, він може містити інформацію по безпеці, ділову інформацію або профіль користувача. Тіло містить запит Web – сервісу або відповідь на нього.

Специфікація описує структуру і тип даних при обміні повідомленнями, використовуючи XML – схему. Спосіб, в якому SOAP використовується для посилки запитів і отримання відповідей від Web – сервіса:

·     Клієнт SOAP використовує документ XML, який узгоджується із специфікацією SOAP і містить запит про послугу.

·     Клієнт SOAP посилає документ серверу SOAP, а той обробляє його за допомогою HTTP, HTTPS.

·     Web – сервіс отримує повідомлення SOAP, направляє його, у вигляді службового запиту, додатку, що надає запрошувану послугу.

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

Лекція 2 Зв'язок Grid та веб-технологій

 

Веб-технології відіграли суттєву роль у справі вільного доступу та спільного використання інтернет-ресурсів. Чергового прориву на цьому шляху, що приведе нас до Веб нового покоління, вже давно очікують від грід-технологій. Вони обіцяють забезпечити зв’язність ресурсів, їх функціональну сумісність на принципово новому рівні, незважаючи на географічні обмеження чи неоднорідність ресурсів. Грід робить можливим спільне використання, вибір, агрегування географічно розподілених, автономних ресурсів залежно від їх доступності, потужності, вартості, адміністративних політик, вимог користувачів до якості обслуговування та надійності тощо. Таким чином, Веб може розглядатися як “інформаційний грід”, а Грід – як “розширений веб”, що позначає те, що Грід йде далі суто інформаційного обміну, надаючи можливість спільного використання комп’ютерних ресурсів (ЦП, пам’ять, сховища, мережі, програми, високоточне обладнання тощо), а не лише інформації. Серед додаткових можливостей, які Грід може потенційно запропонувати порівняно з Веб, можна вказати хоча б такі: автоматичне динамічне оновлення та розширення, конфігурування, підбір ресурсів, автоматичне планування, інтелектуальний синтез знань, автоматичне рішення питань сумісності. Однак, претендуючи на місце у майбутньому Веб, Грід має бути узгоджений з веб-технологіями не лише з концептуального боку, а й з технічного.

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

Розглядаючи грід-систему у статиці, можна представити Грід як множину компонентів – користувачів, апаратних ресурсів, програм, служб. Основу частину компонентів Грід складають грід-ресурси. Під ресурсом можна розуміти будь-який реальний чи уявний об’єкт, до якого потрібно надати доступ іншим сутностям типу користувачів чи програм. Виділяють дві основні категорії грід-ресурсів: фізичні (обчислювальні ресурси, сховища, мережі, периферія), та логічні (дані, знання, прикладні програми). Таке представлення Грід як взаємопов’язаної множини ресурсів відоме як “ресурсно-орієнтоване”. В той же час, ресурси та користувачі Грід перебувають у постійній взаємодії: вони взаємодіють між собою, надсилаючи чи отримуючи запити та відповіді на них, при цьому діючи як незалежні агенти. З такою динамічною поведінкою грід-систем добре узгоджується “сервісно-орієнтований” підхід, базовим поняттям якого є сервіс. Під сервісом можна розуміти деякий програмний модуль із визначеною функціональністю. Мережеве поєднання сервісів, подібне до нейронних структур людського організму, де виходи одного сервісу можуть бути входами для іншого, дозволяє будувати системи зі складною поведінкою. Серед головних принципів сервісно-орієнтованої архітектури (SOA) виділяють наступні: максимальне повторне використання, модульність, здатність до поєднання, функціональна сумісність, відповідність стандартам, можливість ідентифікування, категоризації, моніторингу сервісів. Ці загальні принципи згодом конкретизувалися у наступний перелік:

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

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

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

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

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

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

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

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

Зважаючи на ці особливості та відштовхуючись від сервісно-орієнтованого підходу, підходящою абстракцією для одиниці функціональності Грід є грід-сервіс: спеціалізована автономна служба, що є базовою складовою частиною середовища зі слабкими зв’язками між компонентами, яким є Грід. Наприклад, грід-сервіси, призначені для роботи з даними, взаємодіють з грід-ресурсами сховищ, грід-сервіси для рішення складних обчислювальних задач використовують обчислювальні грід-ресурси тощо. Надалі будемо спиратися на саме таке загальне трактування грід-сервісу як самостійної функціональної одиниці грід-системи, без огляду на технічні деталі його поведінки, реалізації, протоколів. Таке уточнення необхідне, оскільки існує і вузьке конкретне визначення грід-сервісу як веб-сервісу, що надає набір визначених інтерфейсів та слідує певним домовленостям, визначеним у “Відкритій архітектурі грід-сервісів” (OGSA). Для того, щоб розрізняти ці поняття, реалізацію грід-сервісів за OGSA будемо іменувати OGSA-сервісами. Виділяють також базові грід-сервіси, що надають базову функціональність грід-системи користувачам (запуск задач, передача даних, моніторинг та ін.), та прикладні, додаткові, спеціалізовані грід-сервіси, що надають додаткову функціональність (напр., вирішуючи вузькоспеціалізовані обчислювальні задачі таких прикладних областей, як астрономія, біомедицина, фізика тощо) та можуть використовувати у своїй роботі базові грід-сервіси (в т.ч. агрегуючи їх для створення складних середовищ вирішення задач, грід-порталів). Щоправда, реалії Грід вносять деякі уточнення у принципи побудови сервісів. Серед загальних особливостей та вимог саме до грід-сервісів порівняно з принципами SOA варто виділити такі :

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

2.  Підтримка внутрішнього стану. Грід-сервіси можуть слугувати для доступу до реальних об’єктів грід, таких як задачі, файли, апаратні ресурси, програми тощо. В цьому випадку, грід-сервіс має змінювати стан об’єктів, за які він відповідає, у відповідь на вхідні запити. Якщо ж кожному з таких об’єктів поставити у відповідність свій екземпляр грід-сервісу, то цей екземпляр має змінювати свій стан та зберігати його протягом всього часу існування зв’язаного з ним об’єкту. Цей пункт явно суперечить пункту 6 викладених вище принципів SOA.

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

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

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

Вищевикладені пункти потребують деяких уточнень. Наведемо кілька прикладів. Так, якщо сервіс слугує для надання синхронних відповідей на запити типу “надати перелік доступних грід-вузлів”, то йому не потрібно підтримувати механізм оповіщень, існувати постійно між вхідними запитами, підтримувати свій внутрішній стан. Все, що має виконувати такий сервіс – зчитати збережений на поточний момент перелік грід-вузлів з бази даних і передати цю інформацію клієнту. Однак, якщо сервіс слугує для управління конкретною грід-задачею (сама задача представлена як окремий сервіс), то цей сервіс зобов’язаний існувати так довго, як існує сама задача у грід, і кожний новий вхідний запит має змінювати або опитувати поточний внутрішній стан сервісу. Таким чином, грід-сервіси як складова грід-системи не мають певних обов’язкових обмежень на модель поведінки чи особливості життєвого циклу. Ці обмеження вводяться на етапі конкретизації грід-системи у певну архітектурну модель. Так, архітектура OGSA, що успішно реалізована в таких пакетах програмного забезпечення проміжного шару Грід, як Globus Tooklit 4 [10] чи UNICORE [11], зобов’язує грід-сервіс дотримуватись вимог 1-4. Будь-яке інше конкретне архітектурне рішення може відходити від цих вимог, і, можливо, лишатись при цьому життєздатним. Дане дослідження розглядатиме шляхи узгодження грід-сервісів та веб-сервісів з урахуванням можливості забезпечення вимог 1-4, при цьому не орієнтуючись виключно на архітектуру OGSA та сумісність з нею.

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

На сьогодні найбільш популярною технологією, яка реалізує принципи SOA є веб-сервіси. Часто ці терміни навіть помилково сприймають як синоніми. Веб-сервіси визнані надійним рішенням з обміну повідомленнями між сутностями незалежно від їх географічної рознесеності чи технологічної (апаратної, програмної) гетерогенності. Веб-сервіси як платформа для організації міжпрограмної взаємодії добре себе зарекомендувала при побудові інтернет-сервісів B2B, e-Science, e-Government. Їх застосування сприяє впровадженню міжмашинної взаємодії, зменшуючи обсяги ручної, неавтоматизованої роботи користувачів. Будучи добре стандартизованими, веб-сервіси спрощують задачу забезпечення функціональної сумісності та інтеграції компонентів від різних постачальників. Цю задачу значно полегшує і той факт, що веб-сервіси є незалежними від мови програмування чи операційної системи. Стек технологій веб-сервісів, таких як XML, WSDL, SOAP та UDDI, дозволяє на практиці реалізувати принципи SOA на рівні “будь-що є сервісом”. Очевидним є бажання перевірити, чи так само добре підходить технологія веб-сервісів для використання її у архітектурі Грід.

 

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

 

Веб-сервіси

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

Спільні принципи

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

 

Життєвий цикл

Від запита до відповіді, збереження даних у БДМ

Існування між запитами, впродовж часу існування грід-ресурсу

Внутрішній стан

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

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

Оповіщення

Прийнято додаткові стандарти WS-Notification

Мають підтримуватись через специфіку роботи Грід.

Безпека

Стандарти WS-Security

Підтримка GSIМ

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

Визначені, зрілі стандарти

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

 

 

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

До цього моменту було показано, веб-сервіси та грід-сервіси ідеологічно мають і багато спільного, і декотрі відмінності. Уточнимо їх (таблиці 2.1). Ці відмінності традиційно виділяються теоретиками Грід (в основному, учасниками Global/Open Grid Forum) як важливі передумови для введення доповнень у стандарти веб-сервісів. Чи є ці зміни необхідними та принципово неминучими, буде детальніше розглянуто в наступних розділах, а зараз спробуємо лише окреслити можливі шляхи інтеграції грід- та веб-сервісів. Виходячи з того, що грід-сервіси не завжди можуть бути повноцінно реалізовані як веб-сервіси, оскільки веб-сервіси не у всьому сумісні з архітектурою грід [9], то мова може йти про компромісне змішане “Грід-Веб-рішення”. Вже згадані OGSA-сервіси були першою спробою поєднати грід- та веб-сервіси на рівні, близькому до стандартів. OGSA не лише визначила семантику грід-сервісу, а й вказала стандартні механізми створення, іменування, виявлення грід-сервісів, що могли б існувати тривалий час та підтримували внутрішній стан. Як результат, була розроблена специфікація OGSI (Open Grid Services Infrastructure) [12], яка, реалізуючи принципи OGSA, визначала грід-сервіс як веб-сервіс, що відповідає певним домовленостям по інтерфейсам та поведінці. Було визначено, як саме клієнт має взаємодіяти з грід-сервісом стосовно питань управління життєвим циклом, отримання оповіщень, обробки помилок. Ці визначені специфікацією домовленості надавали можливість надійного, безпечного, відмовостійкого управління станом, що звичайно вимагається у розподілених системах типу Грід. З певних причин, які будуть детальніше розкриті згодом, ця специфікація не набула популярності у веб-спільноти. На зміну їй було розроблено сімейство стандартів WSRF (Web Service Resource Framework), вже таки затверджене OASIS. WSRF зосереджується на створенні, адресації, управлінню життевим циклом ресурсів, що мають внутрішній стан. Була проведена межа між веб-сервісом та ресурсом, та вказані шляхи, за допомогою яких клієнт міг звертатися до конкретного ресурсу. У деяких роботах робиться спроба виділити два ортогональні методи інтеграції веб- та грід-сервісів: грід-орієнтовані веб-сервіси та веб-орієнтовані грід-сервіси. Перший підхід полягає у тому, що веб-сервіси набувають деякої грід-специфічної функціональності, тобто “наслідуюються” від грід-сервісів, якщо користуватися об’єктно-орієнтованою термінологією. Другий підхід полягає у тому, що грід-сервіси використовують веб-сервіси як комунікатори, як “базовий клас” для наслідування, таким чином грід-сервіси можуть розглядатися і як стандартні веб-сервіси.

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

 

 

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

Наслідки для...

Адаптація Грід під стандарти веб-сервісів

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

Грід

архітектура грід-сервісів віддаляється від концепції “ресурс-як-сервіс”

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

Веб

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

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

 

 

Як видно, кожен з підходів має свої недоліки: потрібно або переглядати архітектуру грід так, щоб вона була придатна до реалізації на “чистих” веб-сервісах, що не зовсім коректно з ідеологічного боку, або ж треба вносити доповнення до веб-сервісів та ризикувати не дочекатися їх затвердження (у випадку з OGSI) чи прийняття та просування веб-спільнотою. Тепер розглянемо детальніше інтеграційні можливості кожного з цих підходів. Для дослідження першого підходу слід розглянути особливості базових складових технологій веб-сервісів: SOAP, WSDL, UDDI, стандарти WS-*. Другий підхід краще дослідити на прикладах еволюції специфікацій OGSA-OGSI-WSRF.

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

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

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

-      SOAP (Simple Object Access Protocol, простий протокол доступу до об’єктів) як протокол обміну XML-повідомленнями,

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

-      UDDI (Universal Description Discovery & Integration, універсальний опис, виявлення, інтеграція) як стандартний механізм для пошуку сервісів.

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

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

-      реєстр сервісів (UDDI-сховище описів веб-сервісів, в якому публікуються контракти та інші метадані веб-сервісів для їх подальшого пошуку та використання клієнтами);

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

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

Опис : D:\WORK\Dropbox\Акредитація\ris-2-1.JPG

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

 

Після цього будь-який клієнт може дізнатись про існування веб-сервісу та порядок взаємодії з ним, опитавши реєстр. Стандартний UDDI-сервіс реєстру покликаний допомогти в автоматизації процесу пошуку сервісів. Однак допустимим є публікація контракту веб-сервісу і у інші способи – головне, щоб цільові клієнти могли ознайомитись із цим контрактом стосовно інтерфейсу взаємодії із сервісом. Отримавши з реєстру (чи будь-де інде) WSDL-опис веб-сервісу, клієнт може з нього дізнатись, де і як звернутися до сервісу. WSDL є мовою опису інтерфейсів для веб-сервісів. За цим етапом вже слідує безпосередньо етап взаємодії. Клієнт надсилає веб-сервісу дані, загорнуті у SOAP-повідомлення. Зазвичай передача йде по протоколу HTTP. Веб-сервіс розгорнутий на веб-сервері, зі встановленим SOAP-процесором, який дозволяє “розпакувати” дані з XML-повідомлення. Після виконання корисних дій, веб-сервіс повертає клієнту відповідь, загортаючи її назад у HTTP-SOAP-повідомлення. Слід відзначити, втім, що SOAP може використовуватись з будь-яким протоколом прикладного рівня: SMTP, FTP, HTTP та інш. Проте, найчастіше SOAP використовується разом з HTTP. Перш ніж перейти до розгляду окремих компонентів технології веб-сервісів, зробимо кілька коментарів у бік грід-сервісів. Очевидно, що на окремих вузлах грід, де будуть базуватися грід-сервіси, слід встановити контейнер: зв’язку “веб-сервер програм (Application Server) + SOAP-процесор (SOAP engine)” (детальніше про SOAP – див. далі). Допустимі два шляхи: намагатися не залежати від конкретної реалізації контейнера, використовуючи готові відкриті продукти, чи розробити власне спеціалізоване рішення. Спеціалізоване рішення потребуватиме постійної підтримки вузького кола розробників, що може бути занадто обтяжливо, як показав приклад пакету проміжного програмного забезпечення Globus Toolkit 4. Розробники GT4 створили власний контейнер “Java WS Core” на базі Axis 1.x як середовище функціонування WSRF-сервісів (рисунок 2.2). Втім, після досвіду 5 років використання та підтримки було прийнято рішення про припинення розвитку WS-core, оскільки за цей час технології еволюціонували, бібліотеки Axis 1.x та PureTLS застаріли. Це поставило під питання майбутнє WSRF-архітектури базових сервісів Грід, від якої (можливо, тимчасово) відійшли її ж творці у наступній 5-ій версії GT. Цей приклад доводить, що при виборі технічних засобів слід враховувати, наскільки широке коло їх користувачів, стабільність розвитку, підтримку, перспективи, мінливість тих чи інших стандартів, на яких вони базуються.

 

Опис : D:\WORK\Dropbox\Акредитація\ris-2-2.JPG

Рисунок 2.2 – SOAP-контейнер GT4

 

Протокол SOAP (Simple Object Access Protocol)

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

SOAP – простий, заснований на XML, протокол, для обміну інформацією в децентралізованому, розподіленому середовищі. SOAP підтримує різні стилі обміну інформацією, включаючи:

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

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

SOAP характеризується:

-      Протокольною незалежністю.

-      Мовною незалежністю.

-      Незалежністю від ОС і платформи.

-      Підтримкою SOAP XML - повідомлень взаємодіючих частин (використовуючи багатоскладну структуру MIME).

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

Специфікація описує структуру і тип даних при обміні повідомленнями, використовуючи XML – схему. Спосіб, в якому SOAP використовується для посилки запитів і отримання відповідей від Web - сервіса:

-      Клієнт SOAP використовує документ XML, який узгоджується із специфікацією SOAP і містить запит про послугу.

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

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

Встановлюючи правила на структуру повідомлень, придатні і для односторонньої комунікації, SOAP особливо корисний при клієнт-серверній взаємодії у RPC-стилі (запит-відповідь). Одною з вагомих переваг протоколу SOAP над, скажімо, CORBA, є те, що постачальник сервісу не зобов’язаний надавати скомпільовані клієнтські “заглушки” для усіх типів клієнтів (SOAP взагалі не прив’язаний до платформи чи мови програмування). По-друге, протокол SOAP є більш дружнім до файрволів. Однак ці переваги досягаються за рахунок меншої продуктивності, спричиненої витратами на обробку XML-повідомлень.

SOAP-повідомлення є синтаксично коректними (англ. well formed) XML-документами. Структурними елементами є пролог (необов’язковий елемент) з XML-декларацією та SOAP-конверт (пакунок, envelope) – кореневий елемент, який містить елементи заголовку (необов’язковий) та тіла повідомлення:

-      XML Declaration (optional).

-      SOAP Envelope (the root element.

-      SOAP Header (optional.

-      SOAP Body.

Характерними є дві речі: відносно велика частка службових символів (корисна інформація, фактично, полягає у назві методу, типу параметру та його значенні – див. Приклад), та використання просторів імен (namespaces). Використання просторів імен, визначених у XML-схемах, дає, між іншим, можливість застосовувати верифікацію повідомлень на відповідність XML-схемам. Це, звичайно, знизить швидкість обробки. Тобто, протокол SOAP, з одного боку, – простий та незалежний від ОС чи мови програмування, що є перевагою у випадку грід-середовищ. Він добре підходить під модель “запит-відповідь”, допускає механізми автоматизованої перевіки повідомлень на їх відповідність встановленим зразкам, в наявності є автоматизовані засоби для розробників програмного забезпечення (в т.ч. грід-сервісів).

 

Лістинг 2.1 – Простий приклад повідомлення-запиту для методу “піднести ціле число у квадрат” матиме вигляд.

Опис : D:\WORK\Dropbox\Акредитація\f-2-2-1.JPG

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

WSDL-опис

Згідно підходу SOA інтерфейси сервісів мають бути чітко описані та опубліковані. Ця вимога набуває значення, коли в складній архітектурі мають поєднуватись сервіси різних розробників. WSDL-документ – це контракт веб-сервісів, мова WSDL – це мова опису інтерфейсів веб-сервісів. WSDL-опис є також XML-документом, що зручно з точки зору наявних засобів розбору для різних мов програмування. Існує дві специфікації WSDL – перевірена часом і досі популярна 1.1, та офіційно рекомендована W3C у 2007 р. нова версія 2.0. Розглянемо деякі особливості мови WSDL на прикладі версії 2.0, маючи на увазі деякі відмінності між версіями, показані на рисунку 2.3. Опис веб-сервісу можна розділити на дві частини. У абстрактній частині опису веб-сервіс описується за допомогою системи типів (зазвичай з використанням XML-схеми), поняттями повідомлень, які сервіс приймає та відправляє. Шаблони обміну повідомленнями визначають послідовність та кількість повідомлень. Елемент operation зв’язує шаблони обміну повідомленнями з одним або кількома повідомленнями. Елемент interface групує операції (елементи operation) незалежно від протоколу передачі даних. У конкретній частині опису елементи binding задають транспорт та формат доставки для інтерфейсів (елементів interface). Елемент servcie endpoint пов’язує мережеву адресу із елементом binding. Нарешті, елемент service групує елементи endpoint, що реалізують загальний інтерфейс.

 

Опис : D:\WORK\Dropbox\Акредитація\ris-2-5.JPG

Рисунок 2.3 – Відмінності у термінології WSDL 1.1 та 2.0

 

Лістинг 1.2 – Задання параметрів

Опис : D:\WORK\Dropbox\Акредитація\f-2-2-2.JPG

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

UDDI

UDDI (Universal Description, Discovery and Integration) надає відносно незалежний механізм для публікації та пошуку описів сервісів. Він підтримує різні типи описів сервісів, включаючи WSDL-документи, стандартні Java-інтерфейси чи інші XML-документи. У специфікації визначається API реєстру, причому інтерфейс призначений виконувати дві важливі задачі: реєструвати бізнес та його сервіси, і шукати зареєстровані сервіси та прив’язуватись до них. Тобто вузол UDDI-реєстру слугує як провайдер сервісу (публікуючи сервіси), як реєстр сервісів (надаючи можливість проглядати каталог веб-сервісів), та запитувач сервісів (шукаючи запитаний сервіс та прив’язуючи клієнта до нього). І реєстрація, і опитування здійснюються через визначені UDDI-команди, які передаються через SOAP. UDDI насправді представляє собою веб-сервіси, що дозволяють клієнтам реєструвати інтерфейс на вузлі, проглядати, перевіряти, прив’язуватись до зареєстрованих сервісів. Для доступу до цих сервісів UDDI клієнт надсилає SOAP-повідомлення у термінах UDDI-схеми. На рис. показана базова архітектура UDDI-реєстру стосовно запитів. SOAP-запит надсилається до серверу та десеріалізується SOAP-процесором на UDDI-вузлі. Далі виконуються UDDI-запити до реєстру, що перетворюються на запити до бази даних. Відповідь зворотнім порядком через SOAP-процесор для серіалізації та веб-сервер доставляється клієнту (рисунку 2.4).

 

Опис : D:\WORK\Dropbox\Акредитація\ris-2-8.JPG

Рисунок 2.4 – Спрощена схема архітектури UDDI-реєстру

 

Тобто використання UDDI передбачає обмін SOAP-повідомленнями. Можливе створення власних приватних реєстрів для корпоративного інтранету або B2B-мережі. Публічні реєстри різного часу створювались на ibm.com, microsoft.com, sap.com, uddi.org, xmethods.com. Згодом, компанії зосередились на приватних реєстрах, використовуючи UDDI як стандартний механізм реєстрації та пошуку корпоративних сервісів у внутрішній мережі або для представлення своїх сервісів бізнес-партнерам. Реєстри UDDI зберігають інформацію про організації, їх сервіси, і про те, як до цих сервісів отримати доступ. Розроблена модель даних та API які дозволяють публікацію такої інформації та її опитування. Така система часто порівнюється із електронною телефонною книжкою, у якій інформація різних типів проіндексована та представлена відповідним чином. Конкретніше говорять, що UDDI підтримує три типи даних реєстру: «білі сторінки» (довідник бізнес-учасників за іменем), «жовті сторінки» (бізнес за категорією) та «зелені сторінки» (бізнес за сервісами):

-      Білі сторінки – функції UDDI як білих сторінок дозволяють шукати бізнес по імені або якомусь іншому унікальному ідентифікатору типу DUNS чи Thomas Register. Ця інформація доступна через елемент businessEntity.

-      Жовті сторінки – бізнес по категоріям. UDDI також підтримує категоризацію по галузях промисловості, продукції, місцезнаходженню. Ця інформація також пов’язана з елементом businessEntity.

-      Зелені сторінки – умовно позначають можливість UDDI реєструвати бізнес та проглядати зареєстровані записи по типам сервісів та можливостям, які вони надають. Ці можливості надаються елементами businessService та bindingTemplate.

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

-      businessEntity (інформація про організацію-постачальник сервісу)

-      businessService (опис функціональності сервісу)

-      bindingTemplate (технічні тедалі сервісу)

-      tModel (атрибути чи метадані про сервіс, такі як таксономії, транспорт, цифрові підписи тощо)

-      publisherAssertions (відношення між сутностями в реєстрі)

-      subscription (запит на внесення змін до списку сутностей)

Кожна структура даних в реєстрі має унікальний ключ – UUID (Universally Unique ID). Що важливо, реєстр дозволяє побудову різних таксономій для створення семантичної структури інформації, яка зберігається в реєстрі.

 

Опис : D:\WORK\Dropbox\Акредитація\ris-2-9.JPG

Рисунок 2.5 – Структури даних реєстру та приклад їх заповнення

 

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

-              автоматичну реєстрацію сервісів із їх WSDL-описами у реєстрі та

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

 

Таблиця 2.3 – Відповідність елементів WSDL та UDDI (варіант)

WSDL

UDDI

інтерфейси (portType/interface

tModel

portType/interface

tModel

локальна назва portType

tModelName

місцезнаходження WSDL

overviewURL

прив`язка (binding)

tModel

Binding

tModel

binding Namespace

keyedReference у categoryBag

локальна назва binding

tModelName

portType на який посилається binding

keyedReference у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

локальна назва port

InstanceParms у tModelInstanceInfo, що відносяться до tModel прив’язки

binding, вказаний у port

tModelInstanceInfo із tModelKey для tModel, що відноситься до binding

portType, вказаний у port

tModelInstanceInfo із tModelKey для tModel, що відноситься до portType

 

 

 

Таблиця 2.4 – Відповідність елементів BPEL та UDDI (варіант)

WSDL

UDDI

Process

tModel

process Namespace

keyedReference у categoryBag

локальна назва of process

tModelName

місцезнаходження BPEL-документа з описом процесу

overviewURL

WSDL portTypes

portType tModels

Port

bindingTemplate

 

 

Розглядаючи можливість композиції веб-сервісів та автоматичного виконання цілих маршрутів веб-сервісів, описаних мовою BPEL (детальніше – див. у наступних розділах), можливо використати наступні відповідності для відображення BPEL у UDDI (таблиця 2.4). Структури даних UDDI, зокрема, tModel, як вже зазначалося, можуть слугувати для додання семантики в реєстр. Так, можна створити (використати) онтологію веб-сервісів, та прив’язати її елементи до структур UDDI, причому за відсутності відповідників використовуються нові елементи tModel. Таким чином існує можливість створення модулів семантичного пошуку сервісів. У пропонується підхід, який полягає у розширенні структури даних UDDI businessService додатковим елементом serviceProfile, який вказуватиме на збережену DL-онтологію (KIF, DAML, OWL) сервісу. У деяких роботах пропонується подолати обмеженість синтаксичного пошуку UDDI за рахунок «обгортання» інтерфейсу UDDI у компонент-брокер, що підтримує семантичний пошук, та, паралельно із внутрішньою переадресацією запитів до UDDI, опитує базу онтологій.

WS-*

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

WS-Addressing

WS-Addressing встановлює стандартний механізм включення даних про маршрутизацію повідомлень у заголовки 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).

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

WS-Security

WS-Security є гнучким та багатофункціональним доповненням до 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-повідомлень, таким чином працюючи на прикладному рівні. Ці механізми самі по собі не надають повного захисту для веб-сервісів. Замість цього специфікація є конструкційним елементом, який разом із іншими розширеннями для веб-сервісів, дозволить збудувати різноманітні моделі безпеки. Реальна захищеність реалізації цієї специфікації є відповідальністю розробника. Поза увагою цієї специфікації також лежить управління ключами, механізми довіри, технічні домовленості (конкретні шифри, формати, алгоритми).

Приклади захисту 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 як основу для взаємодії, без додаткових протоколів-надбудов. REST-веб сервіси на даний момент не є стандартом, а лише підходом, набором поширених практик.

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

Запит складається із управляючої частини (команди), ідентифікатора ресурса (цілі запиту) та (необов’язкового) представлення ресурса. Відповідь містить метадані ресурса (в довільній формі) та (необов’язкове) представлення ресурса. Загально кажучи, RESTful-веб-сервіс є набором ресурсів, взаємодія з якими відбувається через HTTP-методи GET, PUT, POST та DELETE, та допустимих представлень ресурсів, узгоджених між споживачем сервісу та самим сервісом. При цьому важливим є відповідність логічної операції над ресурсом HTTP-методу. Звичайний варіант наведено в таблиці 2.5.

 

Таблиця 2.5 – Семантика HTTP-операцій в рамках REST-веб-сервісів

Операція

Операнд – колекція ресусрів

Операнд – ресурс

GET

Отримання списку всіх елементів колекції (та їх URI)

Отримання представлення ресурсу

PUT

Заміна колекції на нову

Оновлення ресурсу

POST

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

Ресурс розглядається як окрема колекція – див. POST для колекції

DELETE

Видалення усієї колекції

Видалення ресурсу

 

 

Наприклад, операція «GET http://example.com/grid-tasks/ HTTP/1.1» має наступну семантику: «отримати перелік усіх грід-задач на ресурсі example.com». А, наприклад, операція «POST http://example.com/grid-tasks HTTP/1.1» (далі в тілі повідомлення опис задачі в певному форматі) має такий смисл: «запустити нову грід-задачу на ресурсі example.com». Питання придатності REST-стилю для грід-сервісів набуває актуальності разом із ростом популярності самого REST-підходу). Підтримка 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 тощо).

Семантичні розширення веб-сервісів

Принципи, що лежать в основі веб-сервісів, на диво прості. І вони нічого не додають нового в світ розподілених обчислень і Інтернету:

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

-    будь-який комп'ютер в мережі робить запит до веб-сервісу;

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

Цією дією може бути, наприклад виведення, котирування акцій, виведення ціни на певний продукт, збереження запису в календарі зустрічей, переклад тексту з однієї мови на іншій, або перевірка номера кредитної картки. Веб-сервіси додали новий рівень функціональності, роблячи перший крок в напрямку прозорої інтеграції розподілених компонентів програмного забезпечення, використовуючи веб-стандарти. Проте поточні технології веб-сервісів, засновані на SOAP, WSDL та UDDI, оперують на синтаксичному рівні і вимагають участі людини у їх використанні. Для автоматизації процесів виявлення, компонування та виконання веб-сервісів необхідний їх семантичний опис. Опис веб-сервісів у машинно-зрозумілому форматі дозволяє отримувати більш складну функціональність на основі композиції сервісів, що надаються різними постачальниками. Крім того, це робить можливою інтероперабельність без попереднього узгодження між сторонами. Для забезпечення бази семантичних веб-сервісів, необхідна повна інфраструктура: починаючи від концептуальної моделі, продовжуючи формальною мовою, що надає формальний синтаксис і семантику для цієї моделі, і закінчуючи середовищем виконання, що «склеює» усі компоненти, які використовують цю мову. Серед ініціатив, які пропонують таку інфраструктуру, можна перерахувати декілька: Web-Service Modelling Ontology [5], OWL-S, Semantic Web-Service Framework та WSDL-S.

WSMO

Ініціатива Web-Service Modelling Ontology (WSMO) є одним із основних напрямків у Європі, що має на меті стандартизацію уніфікованої інфраструктури для семантичних веб-сервісів, що забезпечує підтримку концептуального моделювання та формального представлення служб разом із автоматизацією взаємодії з ними. WSMO надає онтологічну специфікацію основних елементів семантичних веб-сервісів. Фактично, семантичні веб-сервіси мають на меті перетворення перехід до нової генерації Веб, де Інтернет перетворений із репозиторію інформації, зрозумілого людині в загально-світову систему розподілених веб-обчислень. Для цього відповідна інфраструктура має інтегрувати базові принципи архітектури Веб, а також принципи розподілених сервіс-орієнтованих систем. Тому WSMO заснований на наступних принципах:

-      Веб-сумісність: WSMO наслідує концепцію Універсального ідентифікатора ресурсу (Universal Resource Identifier, URI) для унікального визначення об’єктів. Крім того, WSMO адаптує поняття просторів імен для цілісних інформаційних областей, підтримує XML та інші технологічні рекомендації W3C поруч із децентралізацією ресурсів.

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

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

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

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

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

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

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

Розглянемо концептуальну модель WSMO. Елементи онтології WSMO описані за допомогою мови мета-мета-моделей на основі Meta Object Facility (MOF). MOF визначає абстрактну мову та інфраструктуру для специфікації, конструювання та керування технологічно-нейтральними мета-моделями. Оскільки WSMO планувався як метамодель семантичних веб-сервісів, MOF був обраний як найбільш підходящий засіб для опису елементів WSMO. В термінах чотирьох шарів MOF (мета-мета-модель, мета-модель, шар моделі та інформаційний шар), мова визначення WSMO відповідає шару мета-мета-моделі, сама WSMO скаладає рівень мета-моделі, власне онтології, веб-сервіси, цілі та посередники складають рівень моделі і фактичні дані, які описані онтологією та передаються між веб-сервісами відповідають інформаційному шару. Найбільш часто використовувана мета-модельна конструкція MOF для визначення елементів WSMO – це Клас (і неявно класоузагальнююча конструкція sub-Class) разом із його Атрибутами, типами Атрибутів та специфікаторами кількості. Для того, щоб дозволити повні описання елементів, кожен із них описується не-функціональними властивостями. Вони базуються на наборі метаданих Dublin Core (DC) для загальних відомостей щодо елемента та інших сервісно-залежних властивостях, пов’язаних із QoS.

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

 

Лістинг 2.3 – Використання MOF

Опис : D:\WORK\Dropbox\Акредитація\f-2-2-3.JPG

 

Як вже було вказано, набір нефункціональних властивостей наявні для характеризування онтологій. Імпортовані онтології дозволяють модульний підхід до дизайну онтології і можуть використовуватись за умови відсутності конфліктів між ними. В реальних умовах при імпорті онтологій, необхідні деякі кроки для зливання та трансформації імпортованих онтологій для розв’язування неспівпадінь. Через це використовуються онтологічні посередники (OO Mediators). Поняття є базовими елементами узгодженої термінології певного проблемного домену. Зв’язки використовуються для моделювання взаємозалежностей між поняттями (та, відповідно, екземплярами цих понять); функції є спеціальним видом зв’язку, із унарним діапазоном та N-мірним доменом (параметри наслідуються зі зв’язку), де значення діапазону функціонально залежне від доменних значень, і екземпляри або визначені явно, або за допомогою посилання на сховище екземплярів (тобто місце окремого від онтології місця їх зберігання).

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

 

Лістинг 2.4 – Використання WSMO

Опис : D:\WORK\Dropbox\Акредитація\f-2-2-4.JPG

 

В середині класу сервіса нефункціональні властивості та імпортовані онтології відвграють таку ж роль, як в класі онтологій, лише із додаванням властивості якості сервіса (quality of service). Додатковий тип посередника (WW Mediator) доданий для вирішення проблеми неспівпадінь віж веб-сервісами, пов’язаних із протоколом. Два останні атрибута визначають два ключові поняття WSMO для семантичного пису веб-сервісів: здатність (capability), яка є функціональним описом веб-сервіса, що визначає обмеження щодо вхідних та вихідних даних служби за допомогою понять передумов, припущень, постумов впливів; та інтерфейс (interface), що визначає як поводиться сервіс для досягнення його функціональності. Інтерфейс служби складається із опису клієнт-среверної взаємодії, що необхідна для споживання сервісу, та опису того, як досягається функціональність веб-сервіса через агрегування інших веб-сервісів.

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

 

Лістинг 2.5 – Окремі сутності найвищого рівня в WSMO

Опис : D:\WORK\Dropbox\Акредитація\f-2-2-5.JPG

 

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

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

 

Лістинг 2.6 – Опис елемента WSMO-посередник

Опис : D:\WORK\Dropbox\Акредитація\f-2-2-6.JPG

 

WSMO визначає різні типи посередників для приєднання окремих елементів: OO Mediators приєднують та забезпечуєть взаємодію між гетерогенними онтологіями, GG Mediators поєднують задачі, WG Mediators з’єднують веб-сервіси із задачами, і WW Mediators забезпечують інтероперабельність між різними веб-сервісами.

OWL-S

OWL-S є веб-сервісною онтологією, заснованою на OWL; її задача – надати будівельні блоки для кодування семантично збагачених описань сервісів способом, що природньо грунтується на OWL. Часто на онтологію OWL-S ontology посилаються як на мову для опису веб-сервісів, таким чином відображуючи той факт, що вона надає словник, що разом із іншими аспектами OWL, може бути використаний для описання сервісів. 
Онтологія OWL-S основним чином складається із трьох взаємопов’язаних суб-онтологій, відомих як профіль, модель процесу та «заземлення». Профіль використовується для вираження того, що сервіс робить для оголошення, конструювання викликів до сервісу та порівняння сервісів; модель процесу описує як це працює для того, щоб дозволити виклик, виконання, композицію, моніторинг та відновлення; і «заземлення» встаовлює відповідність моделі процесу та детальної специфікації форматів повідомлень, протоколів тощо (зазвичай описується за допомогою WSDL).

Усі ці суб-онтології поєднані в поняття Сервіс, яке слугує організаційною точкою посилання для декларування веб-сервісів; завжди, служба оголошена, створюється екземпляр концепції Сервіс. Сервіс має властивості представляє, описаний та підтримує. Класи ServiceProfile (що ідентифікує суб-онтологію профілю), ServiceModel (суб-онтологія моделі процесу) та ServiceGrounding (суб-онтологія прив’язок) – це діапазони значень цих властивостей. Кожний екземпляр Service представляє опис ServiceProfile, описаний ServiceModel, та підтримує ServiceGrounding. ServiceProfile надає засоби опису сервісів, що запропоновані постачальниками та сервісів, що вимагаються споживачами. Не профіль визначає представлення сервісу, а, використовуючи наслідування OWL, спеціалізовані представлення для сервісів можуть бути використані як профілі. Проте, із практичних віркувань, OWL-S забезпечує одне можливе представлення через клас Profile. Сервіс, визначений через профіль OWL-S, моделюється функцією трьох базових типів інформації:

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

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

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

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

-      Трансформація інформації представлена входами та виходами сервісу.

-      Зміна стану внаслідок виконання сервісу представлена передумовами та наслідками сервісу.

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

-      hasParameter: діапазон значень – екземпляри параметрів онтології процесу.

-      hasInput: діапазон значень – екземпляри входів онтології процесу.

-      hasOutput: діапазон значень – екземпляри виходів онтології процесу.

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

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

Оскільки профіль OWL-S описує тільки загальне функціонування сервісу, необхідна детальна перспектива того, як взаємодіяти із сервісом. Ця взаємодія розглядається як процес, і OWL-S визначає субклас ServiceModel для можливості визначити процеси. З точки зору OWL-S, процес – це не обов’язково програма, а більше специфікація шляхів клієнтської взаємодії із сервісом. Процес може генерувати та повертати деяку нову інформацію на основі інформації, що йому надана, та загальному стані. Продукування інформації описується входами та виходами процесу. Також, процес може генерувати зміни загального стану. Ці переходи описується за допомогою передумов та впливів процесу. Будь-який процес може мати будь-яку кількість входів, що представляють інформацію, необхідну за деяких умов для початку процесу. Процеси можуть мати будь-яку кількість виходів, тобто інформації, яку процес надає запитуючій стороні. Входи та виходи представляються як субкласи загального класу 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. Можливі продукти роботи процесу – наслідки (або впливи) та виходи – приєднані до процесу не на пряму. А через властивість hasResult. Хоча властивості, описані попередньо, спільні для всіх процесів OWL-S, існують три їх типи:

-      Атомарні. Описують сервіси, що очікують одне (можливо, складене) повідомлення та повертають одне (можливо, складене) повідомлення у відповідь.

-      Композитні. Процеси, що містять певну інформацію стану; кожне повідомлення клієнта оновлює цей стан.

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

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

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

-      Split: набір процесів, що мають бути виконані одночасно; конструкція виконана, коли усі їз її компонентів заплановані на виконання.

-      Split + Join: набір процесів для паралельного виконання із синхронізацією; завершується, коли усі процеси-учасники завершені.

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

-      Any-Order: Дозволяє процесам-компонентам виконання у будь-якому порядку, але послідовно.

-      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 вивчених під час її розробки уроків. Іншим фундаментальним аспектом у розробці 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, що робить цей підхід незалежним від мови представлення онтології. Перевага цього підходу в тому, що він є інкрементальним, оскільки будується на існуючому стандарті із використанням існуючого досвіду та розробленого інструментарію. До того ж, користувач за допомогою WSDL сумісно аспекти семантичного та операційного рівнів веб-сервісів. Робота WSDL-S керується набором принципів, найважливіші із яких є:

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

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

-      Підтримка анотацій типу даних у XML Schema: Так як XML Schema є важливим форматом визначення даних і бажаним є повторне використання інтерфейсів, описаних за допомогою XML, WSDL-S підтримує анотацію XML схем. Ці анотації використовуються для додавання семантики до входів та виходів анотованого веб-сервіса. Додатково, важливий аспект, який треба взяти до уваги, – це визначення відповідності складних типів XML Schema та онтологічних концепцій. Оскільки WSDL-S не визначає конкретної мови опису, техніка побудови цих відповідностей прямо залежить від обраного семантичного представлення.

WSDL-S пропонує п’ять елементів розширення для використання при анотації входів, виходів та роботи веб-сервісів:

-      modelReference: елемент, що визначає відношення один-до-одного між елементами схеми та поняттями онтології;

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

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

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

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

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

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

Все ж, для реалізації концепції «усе як ресурс», яка може бути моделлю для грід-сервісної інфраструктури, можливостей вищеназваних стандартів може виявитись недостатньо. Група дослідників, що представляла Global (Open) Grid Fourm, послідовно впроваджувала власну концепцію сервісно-орієнтовної архітектури Грід, яка, пройшовши розвиток від загального опису архітектури OGSA [9] до стандарту WSRF, згодом була реалізована в кількох масштабних грід-інфраструктурах. Сформувати рекомендації щодо реалізації грід-сервісів просто неможливо, не взявши до уваги цей цінний досвід.

Головні засади OGSA

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

Семантика грід-сервісу за OGSA

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

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

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

Сервісна модель

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

Сервіси у OGSA характеризуються тими можливостями, які вони надають. OGSA-сервіс реалізує один або більше інтерфейсів, при чому кожен інтерфейс визначає набір операцій, що проводяться шляхом обміну визначеною послідовністю повідомлень. Ці інтерфейси відповідають portType у WSDL. Набір portTypes, які підтримуються конкретним сервісом (та деяка додаткова інформація по версіям), вказаний у елементі serviceType сервісу (розширення WSDL, введене в OGSA).

Грід-сервіси можуть підтримувати власний внутрішній стан (дані стану) протягом свого існування. Наявність стану відрізняє один екземпляр сервісу від іншого, що має той самий інтерфейс.

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

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

Оскільки OGSA-сервіси динамічні та підтримують стан, потрібен спосіб, щоб відрізняти один динамічно створений екземпляр сервісу від іншого. Тому кожний екземпляр грід-сервісу отримує унікальний ідентифікатор – Grid Service Handle (GSH), який відрізняє його від усіх інших існуючих на даний момент, в минулому чи майбутньому екземплярів. В разі, коли сервіс перезапускається зі збереженням стану, він, звичайно, може використовувати той самий GSH.

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

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

Реалізація концепції грід-сервісів: від OGSI до WSRF

Еволюція підходів до реалізації грід-сервісів

Специфікація відкритої інфраструктури веб-сервісів версії 1.0, видана у липні 2003, визначає набір домовленостей та розширень щодо використання мови опису веб-сервісів та XML-схем для реалізації веб-сервісів із підтримкою стану. Вона впроваджує ідею веб-серівісів з підтримкою стану та визначає підходи для створення, іменування та управління життєвим циклом екземплярів сервісів, для визначення та доступу до даних стану, для асинхронного оповіщення про зміну стану, для представлення та керування наборами екземплярів сервісів, і для стандартної обробки помилок виклику сервісів. У січні 2004 була запропонована платформа ресурсів веб-сервісів як рефакторинг та еволюція OGSI, що спирається на використання нових стандартів веб-сервісів, зокрема WS-Addressing, та на досвід від впровадження свого попередника. WSRF зберігає практично усі функціональні можливості OGSI, змінюючи синтаксис (напр., використовуючи WS-Addressing) та впроваджуючи нову термінологію. Додатково, WSRF розбиває функціональність OGSI на 5 різних специфікацій, що можуть поєднуватись. Розглянемо більш детально взаємозв’язки між WSRF та OGSI.

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

Згодом архітектура веб-сервісів еволюціонувала: як приклад – впровадження WSDL 2.0 та вихід специфікації WS-Addressing. Ці розробки змусили переглянути те, як функціональні можливості, закладені у OGSI, використовують функціональність інших специфікацій (зокрема WS-Addressing). Це був слушний час для узгодження функціоналу OGSI із архітектурою веб-сервісів (WS-Arch). Також OGSI 1.0 поєднував в одній специфікації функції, корисні самі по собі, такі як оповіщення. Тому вважалося доцільним розділити OGSI для створення платформи відносно незалежних стандартів.

Як результат такої спроби – набір специфікацій (таблиця 2.6), загальновідомий як платформа ресурсів веб-сервісів [13], в той час, за питання оповіщень (підписка, доставка) відповідає група специфікацій WS-Notification. Разом, ці специфікації зберігають усі суттєві функціональні можливості, присутні у OGSI, впроваджуючи лише зміни у синтаксисі та поняттях. Розбиття OGSI на окремі специфікації дозволяє їх подальше гнучке поєднання. Все це, як вважається, пропонує розробникам більш легкий та послідовний шлях до використання функціональності, закладеній ще у OGSI.

Важливо показати, як саме нові специфікації WSRF та WS-Notification походять від OGSI. Для цього розглянемо, як кожна з конструкцій OGSI реалізована у новіших специфікаціях та вкажемо області, де ці специфікації пропонують відмінні чи вдосконалені можливості.

 

Таблиця 2.6 – Специфікації WSRF

Назва специфікації

Короткі відомості

WS-ResourceProperties

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

WS-ResourceLifetime

Дозволяє запитувачу знищити ресурс негайно або заплановано

WS-RenewableReferences

Додає анотацію до WS-Addressing Endpoint Reference, яка потрібна для отримання нової кінцевої точки, коли поточна стає недійсною

WS-ServiceGroup

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

WS-BaseFault

Описує базовий тип помилки

WS-Notification (сімейство

Стандартні підходи до оповіщень, що використовують шаблон “публікація-підписка”.

 

 

OGSI

Доповнимо та уточнимо викладене вище про OGSI. Специфікація визначає:

-      набір розширень до WSDL, багато з яких вже стали відображені у WSDL 2.0;

-      конструкції WSDL для представлення, опитування, оновлення даних сервісу (метадані та стан);

-      конструкції Grid Service Handle та Grid Service Reference для адресації грід-сервісів;

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

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

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

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

Існує як мінімум 6 (!) різних реалізацій специфікації OGSI, тому було набуто деякий досвід практичного використання OGSI. На додачу, були спроби створити специфікації “верхнього рівня” по відношенню до конструкцій OGSI.

Зміни у стандартах веб-сервісів та критика OGSI

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

WS-Addressing пропонує нейтральний до транспорту (протоколу доставлення повідомлень) механізм адресації веб-сервісів. Специфікація визначає XML-елементи для ідентифікації кінцевих точок (endpoints) веб-сервісу і їх включення до повідомлень. Ця специфікація дозволяє підтримку передачі повідомлень у мережах, що включають вузли обробки, такі як менеджери кінцевих точок, файрволи, шлюзи, незалежно від транспорту. Інформація, яка закладена у посиланні на кінцеву точку, не лише надає адресу самого веб-сервісу, але й може слугувати для ідентифікації конуретних його ресурсів з підтримкою стану через використання відповідних властивостей посилання на кінцеву точку.

WS-MetaDataExchange пропонує ряд механізмів для отримання інформації про опублікований сервіс, такої як WSDL-опис, XML-схема та ін.

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

1.  Специфікація перевантажена. У OGSI не було чіткого розмежування функцій для підтримки послідовного, поступового прийняття. Наприклад, оповіщення є саме по собі корисною функцією, яка не залежить від особливостей роботи із даними сервісу. Сімейства специфікацій WSRF та WS-Notification врахували ці зауваження.

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 включав такі кроки:

1.  введення концепції ресурсу веб-сервісу (WS-Resource);

2.  чіткіше розмежування функцій та вивчення інших специфікацій по веб-сервісам;

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 робить цей факт більш ясним, розмежовуючи обробники повідомлень та ресурси зі станом.

WSRF також зважив і на інші висновки, набуті після публікації специфікації OGSI. Практика показала, що інтерфейс OGSI Factory (фабрика) не настільки корисний, й існували відмінні методи, що досягали тої ж мети. Тому WSRF просто визначає більш загальний шаблон WS-Resource Factory (фабрики ресурсів).

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

OGSI використовує Grid Service Reference (GSR) для адресації сервісу, а також вводить конструкцію Grid Service Handle (GSH) та механізм HandleResolver як один із способів контролю відповідностей між абстрактними, довготривалими іменами та конкретними, імовірно, тимчасовими адресами. Комбінація цих трьох конструкцій дає кілька окремих функцій у взаємозалежному наборі механізмів. WSRF визначає незалежні механізми для цих функцій. Специфікація WS-RenewableReferences визначає можливість стабільності кінцевих посилань шляхом додавання спеціальних політик.

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

Опис : D:\WORK\Dropbox\Акредитація\ris-2-10.JPG

Рисунок 2.6 – Порядок роботи із веб-сервісом, OGSI-сервісом та WSRF-сервісом

 

Розширення GWSDL до portType з WSDL 1.1 в рамках OGSI було більше зайвим “синтаксичним цукром” для розширення інтерфейсу. На додачу, GWSDL йде навіть далі із проголошенням даних сервісу як частини визначення інтерфейсу. На жаль, GWSDL був найбільшою перешкодою використання OGSI. Тому WSRF просто визначає свої повідомлення за допомогою конструкцій WSDL 1.1, та вимагає від розробників складних інтерфейсів просто копіювати та вставляти компоненти таких інтерфейсів до повноцінного переходу на WSDL 2.0.

Приклади реалізації грід-сервісних архітектур

Головними «експлуатантами» специфікацій WSRF є розробники ПЗПШ (програмного забезпечення проміжного шару) Globus Toolkit 4 та UNICORE 6. В обох із них базові грід-сервіси успішно реалізовані з урахуванням засад OGSA таWSRF, однак сама архітектура істотно відрізняється, що піддає сумніву можливість вирішення проблеми функціональної сумісності між ПЗПШ лише за рахунок використання спільних стандартів. На даний момент вже випущена нова версія GT – п’ята, в якій тимчасово призупинено використання WSRF-грід-сервісів. Підтримка усіх особливостей специфікацій WSRF виявилася заскладною для розробників в умовах динамічних змін в технології веб-сервісів. Що ставить під питання доцільність використання специфікацій WSRF, особливо при розробці прикладних грід-сервісів. В роботі [25] обидва ці ПЗПШ досить несподівано порівнюються (протиставляються) із семантичними підходами (WSMO, OWL-S) з точки зору пошуку сервісів, що є натяком на потенційну несумісність грід-сервісів WSRF та існуючих технологій семантичних веб-сервісів.

Щоб додатково дослідити ступінь реальної придатності WSRF для побудови прикладних грід-сервісів, звернемося до існуючого досвіду. Існує чимало спроб використати готовий інструментарій GT чи UNICORE для створення прикладних сервісів (різного ступеня успішності). Зважаючи на потенційні проблеми із семантичним розширенням, додатково звернемо увагу на інший аспект – можливість використання інструментарію з виконання бізнес-процесів (BPEL для веб-сервісів) разом із WSRF-грід-сервісами.

В деяких роботах пропонується архітектура грід-сервісів для біоінформатики. Основними компонентами такої системи є OGSA-DAI для об’єднання гетерогенних ресурсів даних, програма GYM з обробки білкових структур, WSRF-сервіси доступу до них та BPEL-процесор для виконання робочих потоків. Вказано шляхи адаптації BPEL до WSRF-сервісів.

 

Опис : D:\WORK\Dropbox\Акредитація\ris-2-11.JPG

Рисунок 2.7 – Запропонована архітектура, що поєднує BPEL та WSRF

 

Роботи підтверджують потенційну можливість використання BPEL та WSRF на прикладі системи, що використовує графічну нотацію CRESS, середовище ActiveBPEL та грід-сервіси GT4.

Наведемо приклад архітектури (ГІС-системи) для виконання бізнес-процесів в середовищі, де співіснують традиційні веб-сервіси та WSRF-сервіси. Пропонується використовувати єдиний модуль управління робочими потоками, доступ з якого до сервісів різного типу забезпечується через проміжні адаптери та проксі-об’єкти.

У літературі пропонується розширити стандарт BPEL новим видом діяльності gridInvoke задля уможливлення створення потоків WSRF-сервісів. Рішення перевіряється за допомогою інструментарію ActiveBPEL та модулю з візуального створення потоків для середовища проектування Eclipse.

В деяких роботах досліджується можливість використання WS-BPEL-потоків та WSRF-сервісів ПЗПШ UNICORE для виконання потоків наукових задач. Вкзазано специфіку наукових потоків порівняно з традиційними бізнес-процесами: більшу прив’язку до конкретного користувача, залучення передач даних, що ініціюються третьою стороною (third-party transfers), швидка мінливість потоків із накопиченням досвіду. Запропоноване рішення полягає у розробці процесора потоків BIS-Grid, адаптованого під специфіку підсистеми запуску задач даного ПЗПШ.

 

Опис : D:\WORK\Dropbox\Акредитація\ris-2-12.JPG

Рисунок 2.8 – Пропозиція щодо розширення стандарту BPEL задля запуску WSRF-сервісів

 

Нарешті, розглянемо платформау CINWEGS (Collaborative Integrated Web and Grid Services) для узгодженої роботи веб- та грід-сервісів. Серед обраних технічних рішень для реалізації платформи – бібліотека та середовище виконання веб-сервісів Apache Axis, WSRF-сервіси GT4, реєстр Apache jUDDI, процесор робочих потоків ActiveBPEL.

На основі розглянутого вище можна зробити наступні висновки. За формальними ознаками, WSRF є розширенням стандартних веб-сервісів рядом специфікацій, які покликані надати можливість моделювати тимчасові ресурси із власним станом. Практика показала, що при інтеграції WSRF-рішень з існуючими напрацюваннями (stateless веб-сервісами, засобами оркестровки, семантичної розмітки) виникають проблеми, усунення яких вимагає внесення нових уточнень в існуючі стандарти та/або створення проміжних програмних адаптерів. Так, для реалізації концепції WS-ресурсу залучений шаблон фабрики, який є чужим для звичайних веб-сервісів, а також специфічне використання WS-Addressing (рисунок 2.8). Це при тому, що WSRF було спробою виправити ситуацію з OGSA / OGSI, де було впроваджено надзвичайно багато власних рішень, які не могли прижитися у Веб – реєстри, фабрики, GSH/GSR тощо. І хоча декларується, що WSRF є реалізацією OGSA, між ними багато відмінностей.

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

Лекція 3 Grid і бази даних

 

3.1 Розподілені БД

 

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

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

 Щоб почати обговорення пов'язаних з розподіленими СКБД проблем, передусім необхідно утямити, що ж таке розподілена база даних.

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

З цього витікає наступне визначення.

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

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

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

-    Набір логічно пов'язаних розподіоених даних.

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

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

-    Сайти пов'язані між собою мережевими з'єднаннями.

-    Робота з даними на кожному сайті управляється СКБД.

-    СКБД на кожному сайті здатна підтримувати автономну роботу локальних застосувань.

-    СКБД кожного сайту підтримує хоч би одне глобальне застосування.

 Немає необхідності в тому, щоб на кожному з сайтів системи існувала своя власна локальна база даних, що і показане на прикладі топології СКРБД, представленої нарисунку 3.1.

 

image001

Рисунок 3.1 – Топологія   системи   управління розподіленою базою даних

 

Розглянемо приклад розподіленої обробки даних.

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

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

Дуже важливо розуміти відмінності, існуючі між розподіленими СКБД і розподіленою обробкою даних.

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

Крім того, слід чітко розуміти відмінності, існуючі між розподіленими і паралельними СКБД.

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

Переваги і недоліки, властиві розподіленим СКБД

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

Переваги:

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

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

Підвищення надійності

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

Підвищення продуктивності

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

Економічні вигоди

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

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

Модульність системи

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

Недоліки:

Підвищення складності

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

Збільшення вартості

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

Проблеми захисту

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

Ускладнення контролю за цілісністю даних

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

Відсутність стандартів

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

Недолік досвіду

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

Ускладнення процедури розробки бази даних

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

Усі переваги і недоліки, властиві розподіленим СКБД, перераховані в таблиці 3.1.

 

Таблиця 3.1 – Переваги і недоліки розподілених СКБД

Переваги

Недоліки

Відображення структури організації

Підвищення складності

Розделяємість і локальна автономність

Збільшення вартості

Підвищення доступності даних

Проблеми захисту

Підвищення надійності

Ускладнення контролю за цілісністю даних

Підвищення продуктивності

Відсутність стандартів

Економічні вигоди

Недолік досвіду

Модульність системи

Ускладнення процедури розробки бази даних

 

 

3.2 Гомогенні і гетерогенні розподілені СКБД

 

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

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

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

-    інший тип використовуваного устаткування;

-    інший тип використовуваної СКБД;

-    інший тип використовуваного устаткування і СКБД.

Якщо використовується інший тип устаткування, проте на сайті встановлений той же самий тип СКБД, методи виконання трансляції цілком очевидні і включають заміну кодів і зміну довжини слова. Якщо типи використовуваних на сайтах СКБД різні, процедура трансляції ускладнюється тим, що необхідно відображувати структури даних однієї моделі у відповідні структури даних іншої моделі. Наприклад, відношення в реляційній моделі даних мають бути перетворені в записи і набори, типові для мережевої моделі даних. Крім того, потрібно буде транслювати текст запитів з однієї використовуваної мови на іншій (наприклад, запити SQL-оператор SELECT потрібно буде перетворити в запити з операторами FIND і GET мови маніпулювання даними сіткової СКБД). Якщо відрізняються і тип використовуваного устаткування, і тип програмного забезпечення, потрібно буде виконувати обидва види трансляції. Усе викладене вище назвичайно ускладнює обробку даних в гетерогенних СКБД.

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

Розробка розподілених реляційних баз даних

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

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

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

-              Реплікація. СКРБД може підтримувати актуальну копію деякого фрагмента на декількох різних сайтах.

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

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

Централізоване розміщення

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

Роздільне (фрагментоване) розміщення

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

Розміщення з повною реплікацією

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

Розміщення з вибірковою реплікацією

Ця стратегія є комбінацією методів фрагментації, реплікації і централізації.

 

3.3 Фрагментація. Призначення фрагментації

 

Коректність фрагментації

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

-              Повнота. Якщо екземпляр відношення R розбивається на фрагменти, наприклад R1,  R2,.., Rn, то кожен елемент даних, присутній відносно R, має бути присутнім, принаймні, в одному із створених фрагментів. Виконання цього правила гарантує, що які-небудь дані не будуть втрачені в результаті виконання фрагментації.

 

Таблиця 3.2 – Порівняльні характеристики різних стратегій розподілу даних

Розміщення даних

Локальність посилань

Надійність і доступність

Продуктивність

Вартістьпристроїв зберігання

Витрати на передачу даних

Централізоване

Найнижча

Найнижча

Незадовільна

Найнижча

Найвищі

Фрагментованое

Висока1

Низька для окремих елементів; висока для системи в цілому

Задовільна1

Найнижча

Низькі

Повна реплікація

Найвища

Найвища

Хороша для операцій читання

Найвища

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

Вибіркова реплікація

Висока1

Низька дляокремих елементів, висока для системи

Задовільна 1

Середня

Низькі

 

  1 За умови якісного проектування.

 

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

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

У разі горизонтальної фрагментації елементом даних являється кортеж, а у разі вертикальної фрагментації – атрибут.

Типи фрагментації

Існують два основні типи фрагментації: горизонтальна і вертикальна. Горизонтальні фрагменти є підмножинами кортежів відношення, а вертикальні – підмножини атрибутів відношення, як показано на рисунку 3.2.

 

image002

Рисунок 3.2 – Різні   типи   фрагментації : а) горизонтальна; б) вертикальна

 

Крім того, існують ще два типи фрагментації: змішана (рисунок 1.13) і похідна (що є варіантом горизонтальної фрагментації).

 

image003

Рисунок 3.3 – Змішана фрагментація: а) горизонтально розділені вертикальні фрагменти; б) вертикально розділені горизонтальні фрагменти

 

 Відмова від фрагментації

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

Забезпечення прозорості в РСКБД

Розподілені СКБД можуть забезпечувати різні рівні прозорості. Проте у будь-якому випадку переслідується одна і таже мета: зробити роботу з розподіленою базою даних абсолютно аналогічної роботі із звичайною централізованою СКБД. Виділимо чотири основні типи прозорості, які можуть мати місце в системі з розподіленою базою даних.

-              Прозорість розподіленості.

-              Прозорість транзакцій.

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

-              Прозорість використання СКБД.

Прозорість розподіленості

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

Прозорість транзакцій

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

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

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

Прозорість виконання вимагає, щоб робота в середовищі СКРБД виконувалася точно так, як і в середовищі централізованої СКБД.

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

-              час доступу, що включає фізичний доступ до даних на диску;

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

-              час, необхідний для передачі даних по мережевих з'єднаннях.

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

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 оглядів об'єктів нерухомості. Вважатимемо також, що час виконання обчислень несуттєвий в порівнянні з часом передачі даних, а швидкість передачі даних по каналах зв'язку складає 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, після чого пере-слать отриманий результат в Глазго для відбору кортежів по ус-ловию Max Price > 200 000 фунтів стерлінгів.  Для спрощення припустимо, що довжина кортежу після операції проекції також дорівнює 100 символам.

Час = 1 + (100 000 * 100/10 000) = 16,7 хв.

Стратегія 6.

Вибрати клієнтів зі значенням атрибуту Max_Price > 200 000 фун-тов стерлінгів в Глазго і переслати результуючу таблицю в Лондон для відбору відомостей про огляди об'єктів нерухомості в р. Абердин:

Час = 1 + (10 * 100/10 000) ≈1с.

 

 

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

Стратегія

Час

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с.

 

 

 Прозорість використання СКБД

Прозорість використання СКБД дозволяє приховати від користувача СКРБД той факт, що на різних сайтах можуть функціонувати різні локальні СКБД. Тому цей тип прозорості застосовний тільки у разі гетерогенних розподілених систем. Як правило, це один з найскладніших в реалізації типів прозорості.

Декілька слів на закінчення

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

Дванадцять правив Дейта для РСКБД

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

Правило 0. Основний принцип

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

Правило 1. Локальна автономність

Сайти в розподіленій системі мають бути автономними. У даному контексті автономність означає наступне:

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

-    усі локальні процеси залишаються чисто локальними;

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

Правило 2. Відсутність опори на центральний сайт

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

Правило 3. Безперервне функціонування

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

-    додавання або видалення сайту з системи;

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

Правило 4. Незалежність від розташування.

Незалежність від розташування еквівалентна прозорості розташування. Користувач повинен діставати доступ до бази даних з будь-якого з сайтів. Більше того, користувач повинен діставати доступ до будь-яких даних так, як якби вони зберігались на його сайті, незалежно від того, де вони фізично зберігаються.

Правило 5. Незалежність від фрагментації

Користувач повинен діставати доступ до даних незалежно від способу їх фрагментації.

Правило 6. Незалежність від реплікації

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

Правило 7. Обробка розподілених запитів

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

Правило 8. Обробка розподілених транзакцій

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

Правило 9. Незалежність від типу устаткування

СКРБД має бути здатна функціонувати на устаткуванні з різними обчислювальними платформами.

Правило 10. Незалежність від операційної системи

Прямим наслідком попереднього правила є вимога, згідно з яким СКРБД має бути здатна функціонувати під управлінням різних операційних систем.

Правило 11. Незалежність від мережевої архітектури

СКРБД має бути здатна функціонувати в мережах з різною архітектурою і типами носія.

Правило 12. Незалежність від типу СКБД

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

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

 Резюме

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

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

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

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

-    Аналогічно тому, як централізована СКБД повинна надавати опреде-ленный набір стандартних функцій,  розподілена СКБД повинна надавати розширені можливості установки з'єднань, включати розширену службу системного каталогу, забезпечувати розподілену обробку запитів, підтримувати розширені засоби розпаралелювання операцій, а також мати власну службу відновлення.

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

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

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

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

 Керування розподіленою паралельністю.

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

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

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

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

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

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

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

-    Модель X/Open DTP являє собою один з варіантів архітектури обробки  розподілених  транзакцій,   побудованої   на  застосуванні  протоколу OSI - TP і двофазного протоколу фіксації транзакцій. У цій моделі визначаються прикладні програмні інтерфейси й методи взаємодії між додатками, що запускають транзакції, менеджерами транзакцій, менеджерами ресурсів і менеджерами передачі даних.

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

Лекція 4. Управління Grid-оточенням

 

4.1 Управління розподіленими транзакціями

 

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

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

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

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

-    Компонент передачі даних на вузлі – відправляє опис відповідних субтранзакцій на вузли S2 і S3.

-    Координатори транзакцій на вузлах S2 і S3 організовують виконання субтранзакцій, що поступили. Результати їх виконання передаються координаторові TC1 за допомогою компонентів передачі даних. Увесь описаний процес схематично представлений на рисунку 4.1.

 

image004

Рисунок 4.1 – Схема координації виконання розподілених транзакцій

 

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

 

4.2 Управління паралельним виконанням в розподіленому середовищі

 

У цьому розділі будуть представлені протоколи, які можуть використовуватися для організації управління паралельним виконанням в розподілених СКБД. Але спочатку слід ознайомитися з цілями, які стоять перед механізмом управління паралельним виконанням в розподіленому середовищі.

Цілі управління паралельним виконанням в розподіленому середовищі

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

-    стійкість до відмов на вузлі і в лініях зв'язку;

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

-    невисокий додатковий рівень споживання процесорного  часу і інших системних ресурсів;

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

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

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

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

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

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

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

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

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

 

4.3 Протоколи блокування

 

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

Централізований протокол двофазного блокування

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

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

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

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

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

Перевага централізованого протоколу двофазного блокування полягає в тому, що його можна відносно просто реалізувати. Виявлення взаимоблокировок може виконуватися тими ж методами, що і в централізованих СКБД, оскільки уся інформація про блокування елементів знаходиться у розпорядженні єдиного диспетчера блокувань. Основний недолік цієї схеми пов'язаний з тим, що будь-яка централізація в розподіленій СКБД автоматично призводить до появи вузьких місць в системі і різко знижує рівень її надійності і стійкості. Оскільки усі запити на блокування елементів даних прямують на єдиний центральний вузол, його швидкодія обмежує можливості усієї системи. Крім того, відмова цього вузла викликає порушення роботи усієї розподіленої системи, тому вона стає менш надійною. Проте цій схемі властивий відносно невисокий рівень витрат на передачу даних. Наприклад, глобальна операція оновлення за участю агентів (субтранзакцій) на вузлах за наявності центрального диспетчера блокувань може потребувати відправки йому не менше 2n + 3 повідомлень, у тому числі:

-              один запит на блокування;

-              одне повідомлення про надання  блокування;

-              n сполучень з вимогою оновлення;

-              n підтверджень про виконане оновлення;

-              один запит на зняття блокування.

Двофазне блокування з первинними копіями

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

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

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

Розподілений протокол двофазного блокування

У цьому протоколі також робиться спроба подолати недоліки, властиві централізованому протоколу двофазного блокування, але вже за рахунок розміщення диспетчерів блокувань на кожному вузлі системи. В даному випадку кожен диспетчер блокувань відповідає за управління блокуванням даних, таких, що знаходяться на його вузлі. Якщо дані не піддаються реплікації, цей протокол функціонує аналогічно протоколу двофазного блокування з первинними копіями. Інакше розподілений протокол двофазного блокування використовує особливий протокол управління реплікацією, що дістав назву "Читання однієї копії і оновлення усіх копій" (Read - One - Write - All - ROWA). В цьому випадку для операцій читання може використовуватися будь-яка копія копійованого елементу, але перш ніж можна буде відновити значення елементу, мають бути встановлені виняткові блокування на усіх копіях. У такій схемі управління блокуваннями здійснюється децентралізованим способом, що дозволить позбавитися від недоліків, властивих централізованому управлінню. Проте цьому підходу властиві свої недоліки, пов'язані з істотним ускладненням методів виявлення взаємоблокувань (через наявності багатьох диспетчерів блокувань) і зростанням витрат на передачу даних (в порівнянні з протоколом двофазного блокування з первинними копіями), які викликані необхідністю блокувати усі копії кожного оновлюваного елементу. У цьому протоколі виконання глобальної операції оновлення, що має агентів на n вузлах, зажадає передачі не менше 5n повідомлень, у тому числі:

-    n сполучень із запитами на блокування;

-    n сполучень з наданням блокування;

-    п сполучень з вимогою оновлення елементу;

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

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

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

Блокування більшості копій

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

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

 

4.4 Протоколи з часовими відмітками

 

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

Загальним підходом в розподілених СКБД є конкатенація локальної часової відмітки з унікальним ідентифікатором вузла у форматі <локалъная_відмітка, ідентифікатор_вузла>. Значення ідентифікатора вузла має менший ваговий коефіцієнт, що гарантує впорядкування подій відповідно до моменту їх виникнення і лише потім відповідно до місця їх появи. Щоб запобігти виробленню більш завантаженими вузлами великих значень часових відміток в порівнянні з недовантаженими вузлами, необхідно використовувати певний механізм синхронізації значень часових відміток між вузлами. Кожен вузол поміщає свою поточну часову відмітку в повідомлення, що передаються на інші вузли. При отриманні повідомлення вузол-одержувач порівнює поточне значення його часової відмітки з отриманим і, якщо його поточна часова відмітка виявляється менше, міняє її значення на деяке інше, що перевищує те значення часової відмітки, яке було отримано ним в повідомленні. Наприклад, якщо вузол 1 з поточною часовою відміткою <10, 1> передає повідомлення на вузол 2 з поточною часовою відміткою <15,2>, то вузол 2 не змінює свою часову відмітку. І навпаки, якщо поточна часова відмітка на вузлі 2 рівна <5, 2>, то вузол 2 повинен змінити свою часову відмітку на <11, 2>.

 

4.5 Технології 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 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), де воно розбирається, аналізується і звідки посилається команда на сервер, як показано на рис. 4.2.

 

image005

Рисунок 4.2 – Схема роботи OLE Automation

 

Наочніше ця ж схема, але вже в специфікації СОМ, представлена на рис. 4.3.

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

У дистанційній моделі, яка тепер замість СОМ дістала назву DCOM, ініціалізатор і перехідник стали абсолютно іншими, тепер в них використовуються процедури дистанційного виклику (RPC) для передачі запитів клієнта по мережі до модуля Remote Server Process, що функціонує на сервері. Клієнтська частина DCOM, аналогічна колишньому механізму Automation Manager, передає дані клієнта вказаному OLE-серверу і дані у відповідь по мережі до програми-клієнта, як показано на рис. 1.15.

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

 

image006

image007

Рисунок 4.3 – Схема взаємодії для локального і віддаленого варіантів

 

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

Реалізація цієї можливості є ключовим моментом в створенні трирівневої архітектури ділових застосувань Microsoft, в якій частина призначеного для користувача інтерфейсу розміщена на робочій станції клієнта, бізнес-логіка – на сервері середнього рівня, а надпотужні засоби обробки даних – на SQL-сервері бази даних (рис. 4.4).

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

 

image008

Рисунок 4.4 – Трирівнева архітектура бізнес-застосувань

 

Проте у фірмовій документації Microsoft, присвяченій OLE-об’єктам, стверджується: "Найчастіше розміщення сервер-об’єктів доступу до даних на тій машині, де знаходиться база даних, може істотно скоротити завантаження мережі і збільшити загальну швидкість передачі даних". Є приклади реалізації трирівневих клієнт-серверних застосувань, де результати перевершують усі очікування. Продуктивність мережі практично перестає впливати на час обробки транзакцій, і своєрідне розпилювання монолітних програмних блоків на мобільні OLE-сегменти приводить до значного підвищення ефективності роботи застосування в цілому. Більше того, трафік в мережі істотно зменшується і стає більше передбачуваним.

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

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

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

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

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

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

 Що мається на увазі під технологіями ActiveX

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

Стандарт ActiveX дозволяє програмним компонентам взаємодіяти один з одним по мережі незалежно від мови програмування, на якій вони написані. За допомогою ActiveX можна "оживити" Web-сторінки ефектами мультимедіа, інтерактивними об'єктами або складними застосуваннями. ActiveX забезпечує деякі зв'язні засоби, за допомогою яких окремі програмні компоненти на різних комп'ютерах "склеюються" в єдину розподілену систему.

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

 Керуючі елементи ActiveX (ActiveX Controls)

Що ж це таке насправді? Найбільш проста відповідь – ця нова назва для керуючих  елементів OCX, або навіть для ще раніше них існуючих VBX. Будь-який готовий або створений вами управляючий елемент OLE – це вже ActiveX-елемент, який може використовуватися в програмах. Проте подібні OLE-елементи в усьому їх незліченному різноманітті навряд чи влаштують розробників для Web.

Типовий недолік існуючих 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-вузлах.

Оскільки ActiveX-файл є родичем VBX, він може використовуватися і в звичайному Visual Basic, і в мові сценаріїв VBScript. У таблиці 4.1 перераховані основні бібліотечні типи, що використовуються у Windows.

 

Таблиця 4.1 – Бібліотечні типи, використовувані в Windows

Управляючий елемент

Розши-рення

Функція

Бібліотеки (Dynamic link library), що динамічно підключається

.dll

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

Visual Basic

.vbx

Забезпечує той же призначений для користувача сервіс, що і DLL. Може застосовуватися в інтегрованих середовищах розробки, таких як Visual Basic 3.0, MSVC++ 1.52 і Delphi 1.0

ActiveX

.OCX

Забезпечує призначений для користувача сервіс, такий же, як DLL, і той же, що і VBX. На додаток, OCX є більш функціональними і краще використовує усі доступні йому ресурси. Підтримується практично усіма відомими RAD-системами

 

 

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

Контейнер і взаємодія з ним

Управляючий елемент ActiveX не може існувати сам по собі, він завжди "живе" усередині свого контейнера і тісно взаємодіє з ним. Через властивості оточення (ambient properties) об'єкт має доступ до інформації про поточний стан свого "власника". Контейнер підтримує додаткові методи, властивості і події, які для розробника виглядають як частину інтерфейсу елементів управління 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 має стандартний інтерфейс. Ви можете написати свої обробники для подій, генерованих цим об'єктом, надати для використання або перевизначити стандартні властивості. Так само ваш 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 повинне працювати і взаємодіяти з іншими 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 є прообразом нашого об'єктного майбутнього. У комп'ютерному світі абсолютно нормальним вважається факт, що програмісти усіх країн по мільйону разів переписують наново один і той же алгоритм, якщо він вимагає внесення деяких невеликих змін. Навіщо?

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

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

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

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

Приклади абсолютно прості: ви включаєте свій телевізор таким самим способом, як праску, електропіч або настільну лампу. Усі предмети, що відносяться до класу "Прилад", містять метод "включити", але в процесі включення, залежно від типу приладу (підкласу), єдиний метод "включити" поводиться поліморфно, тобто викликає абсолютно різні електричні і блокові функції: для праски – одні, для телевізора – інші. Можна так перевизначити класи і методи в телевізорі новітньої конструкції, що він поводитиметься абсолютно по-різному, залежно від того, ХТО його включив, тобто телевізор поведеться поліморфно. Більше того, існують програмні засоби (Java+XML), які здатні динамічно модифікувати контент. Попри те, що Java і XML самі по собі досить складні, інструменти, засновані на них, для звичайного користувача надзвичайно прості і приємні, бо вони відводять його від необхідності знати внутрішні механізми інформаційного джерела і призводять до дистанційного пульта управління ними.

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

Для постмодерністської епохи, завершенням якої є Інтернет, цінності в традиційному розумінні не є цінностями, бо вона маніпулює ними і будує з них структури більш високого порядку. Плоть і кров пішли з цивілізованих людей, залишилася лише електрика. Безглуздо заявляти свої права на конструкції, які існують як візерунки в калейдоскопі. Усе стає віртуальним, усе стає відносним, а точка відліку – Мережа. Сучасні люди вже не здатні круто змінити парадигму свого існування. Творчість в епоху Інтернету є витяганням усе нових і нових сенсів з відомих речей і постійне оновлення простору контенту.

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

Архітектура CORBA.

Чотири головні елементи CORBA архітектури показані на рис. 4.5.

-              Брокер об'єктних запитів (ORB – Object Request Broker) визначає механізми взаємодії об'єктів в різнорідній мережі. Посередник об'єктних запитів, ORB, або просто брокер, – це логічне ядро системи. Саме він дозволяє об'єктам посилати запити і отримувати відповіді від інших об'єктів в мережі. ORB – це проміжне програмне забезпечення, яке встановлює відношення між об'єктами в розподіленому середовищі. Брокер по посиланню знаходить на сервер, що містить об'єкт-адресат (object implementation – реалізація об'єкту); активізує його, доставляє до нього запит; передає параметри і викликає відповідний метод, після чого повертає результат клієнтові. Ролі клієнта і сервера при цьому можуть мінятися. Взаємодія може бути встановлена між безліччю об'єктів. OMG розробив спеціальну мову верхнього рівня для опису ORB і інших компонентів CORBA – так званий IDL (Interface Definition Language – мова опису інтерфейсів). У ній немає присвоєнь,    звичайних    мовних    конструкцій,    типу    if    чи    while, функцій і логічних переходів і т. д. IDL – це мова декларацій, вона описує батьківські класи, події і методи. Кожен інтерфейс визначає операції, які можуть бути викликані клієнтами, але не те – яким чином ці операції виконуються зовні IDL і CORBA. У цьому і привабливість – можна змусити працювати старі програми, якщо правильно описати їх інтерфейси і використати компілятор з IDL, який має відображення в конкретну мову програмування. Важливо зрозуміти, що є два типи інтерфейсів: динамічні і статичні. Перші визначаються на стадії розробки застосування і компілюються разом з ним, другі конструюються у момент виконання, на працюючому застосуванні.

-    Сервіси  об'єктів  (Object  Services)  є  основними  системними сервісами, які розробники використовують для створення застосувань.

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

-    Прикладні об'єкти  (Application  Objects)  використовуються  в конкретних прикладних завданнях.

Так, все-таки, навіщо потрібна CORBA?

 

image009

Рисунок 4.5 – Головні елементи CORBA

 

Розподілені застосування

CORBA-архітектура забезпечує каркас для розробки і виконання розподілених застосувань. Але виникає нове питання – а навіщо взагалі потрібний цей розподіл? Як тільки ви зіткнетеся з ним, то побачите перед собою величезну купу нових проблем. Проте іноді немає іншого вибору: деякі застосування просто вимагають бути розподіленими з наступних причин:

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

-    обчислення – розподілені;

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

Розподілені дані

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

Розподілені обчислення

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

Розподілені користувачі

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

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

Брокер об'єктних запитів, ORB, ставить запит об'єкту і повертає будь-який результат клієнтові (рис. 4.7).

 

image0010

Рисунок 4.6 – Розподілені користувачі

 

image0011

Рисунок 4.7 – Механізм взаємодії: клієнт запитує об'єкт через посередника ORB

 

Від клієнта до сервера

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

Можна чітко сформулювати ключові особливості CORBA-стандарту:

-    CORBA-об’єкти можуть знаходитись в будь-якому месці мережі;

-    CORBA-об’єкти можуть взаємодіяти з іншими CORBA -объектами на будь-яких платформах;

-    CORBA-об’єкти можуть бути написані на будь-якій мові програмування, для якого є інтерфейс, що реалізовується IDL-компілятором (такі є для Java, C++, C, SmallTalk, COBOL і Ada).

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

 

image0012

Рисунок 4.8 – Архітектура CORBA-сумісного застосування, що викликає безліч об'єктів з безлічі комп'ютерів

 

Клієнтська частина CORBA

Коли CORBA-сумістний об'єкт використовує метод, що знаходиться в іншому об'єкті, він викликає стаб (stub), тобто деяку порожню оболонку необхідного об'єкту, його інтерфейсну частину, що знаходиться в спеціальному stub-файлі. Цей стаб використовує локальний ORB, посилає запит і отримує відповідь. Об'єкту немає ніякої необхідності знати подробиці відносно 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 Служить для забезпечення інтерфейсу до кожного сервісу. На серверній стороні такої стаб, щоб відрізнити його від клієнтського стаба, називається скелетон.

-    Implementation Repository Це набір класів на стороні сервера, доступний усім розподіленим клієнтам через систему об'єктних посилань.

Сервіси CORBA

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

 

image0013

Рисунок 4.9 – Об'єктні сервіси

 

Є безліч CORBA-сервісів. Найпопулярніші з них наведені в таблиці 4.2.

 

Таблиця 4.2 – Найбільш популярні сервіси CORBA

Сервіс

Опис

Життєвий цикл об’єкта (Object life cycle)

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

Іменування (Naming)

Визначає спосіб символічного позначення CORBA -объектов

Події (Events)

Обробка подій

Відношення (Relationships)

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

Перетворення об'єктів з однієї форми в іншу (Externalization)

Координує перетворення об'єктів із зовнішніх форм у внутрішні і навпаки

Транзакції (Transactions)

Координують доступ до CORBA-об’єктів

Контроль доступу (Concurrency Control)

Забезпечує обслуговування блокування об'єктів CORBA

Властивість (Property)

Підтримує   асоціацію   пари :   ім'я-значення для об'єктів CORBA

Продавець (Trader)

Підтримує  пошук  CORBA-об’єктів,   заснований на афішованих властивостях об'єкту

Запрос (Query)

Підтримка запитів до об'єктів

 

 

CORBA-продукти

Не забувайте, що CORBA – це усього лише специфікація. Що стосується програмних виробів, що реалізовують архітектуру CORBA, то їх є множина. Окремі продавці забезпечують свої брокери CORBA і IDL для відображення в різні мови програмування. Усі вони зобов'язані підтримувати Java. У таблиці. 4.3 приведені найбільш відомі реалізації CORBA.

 

Таблиця 4.3 – Найбільш відомі реалізації 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-реалізації для різних мов програмування доступні для завантаження по мережі Інтернет з різних джерел

 

 

4.6 Розподілені об’єктні технології в інформаційних системах

 

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

Складність створення, модифікації, супроводження та інтеграції ІС, особливість розв’язуваних з їх використанням задач, визначає такі їх класи:

−           малі ІС;

−           середні ІС;

−           крупні ІС (корпоративні на рівні загальнодержавних установ).

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

−           нетривалий життєвий цикл;

−           орієнтація на масове використання;

−           невисока ціна;

−           практична відсутність засобів аналітичної обробки даних;

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

−           використання, головним чином, настільних СУБД (Clarion, FoxPro, Clipper, Paradox, Access та ін.);

−           однорідність апаратного та системного забезпечення (недорогі персональні комп’ютери (ПК));

−           практична відсутність засобів забезпечення безпеки;

−           та ін.

Ознаками класу середніх ІС є:

−           тривалий життєвий цикл і можливість росту до крупних ІС;

−           наявність аналітичної обробки даних;

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

−           наявність засобів забезпечення безпеки;

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

−           та ін.

До характерних ознак корпоративних ІС відносяться:

−           тривалий життєвий цикл;

−           міграція успадкованих систем

−           розмаїття використовуваного апаратного забезпечення з меншим, порівняно

−           із створюваною системою, життєвим циклом;

−           розмаїття використовуваного програмного забезпечення (ПЗ);

−           масштабність та складність розв’язуваних задач;

−           перетин множини різних предметних галузей;

−           орієнтація на аналітичну обробку даних;

−           територіальний розподіл;

−           та ін.

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

Сучасний рівень розвитку суспільства визначає індустрію ІТ, як провідний і стратегічний напрямок зосередження інтелектуальних та фінансових ресурсів. Інформація та інструменти управління нею (програмні продукти різного функціонального призначення) набули статусу інформаційних ресурсів (ІР). Останні концентруються в рамках ІС. Об’єднання ресурсів на основі інформаційно-комунікаційної взаємодії ІС виводить їх на рівень корпоративних інформаційних ресурсів. Це об’єднання часто називають Єдиним Інформаційним Простором (ЄІП). Реалізація ЄІП на рівні держави, корпорації, підприємства можливе у разі створення з подальшим дотриманням стандарту на взаємодію між собою ІС, та їх окремих додатків, рис. 4.10

 

Рисунок 4.10 - Корпоративні інформаційні ресурси

 

У ряді випадків під ІР розуміють тільки дані, коли розв’язок проблеми ЄІП зводиться до Єдиного Простору Даних (ЄПД), рис. 4.11, а ІС виступають як клієнт та сервер і взаємодіють один з іншим у відповідності із схемою, наведеною на рис. 4.12.

 

 

 

Рисунок 4.11 - Єдиний простір даних (ЄПД)

 

Рисунок 4.12 - Архітектура доступу до віддалених даних

 

Інформаційна система-клієнт (ІСК) надсилає інформаційній системі-серверу (ІСС) запит, отримуючи, як результат, дані, які підлягають подальшій обробці. Як запит, використовують мову SQL - стандарт поводження з реляційними системами управління базами даних. Доступ до віддалених баз даних (БД) у більшості випадків здійснюється з використанням продуктів, які підтримують протоколи ODBC (Open Data BaseConnectivity), та JDBC (Java Data Base Connectivity), або використовуються шлюзи, які постачаються виробниками СУБД чи третіми фірмами-виробниками. При побудові єдиного простору даних використовується архітектура доступу до віддалених даних, що є аналогом дворівневої архітектури клієнт-сервер. Ця архітектура припускає реалізацію на стороні клієнта як функцій введення та відображення даних, так і прикладних функцій додатку, тобто методів обробки даних. Клієнт направляє запити до сервера, який обробляє їх і повертає клієнту результат, оформлений як блок даних.

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

-    слід знати з боку ІСК особливості використовуваної СУБД та структуру віддаленої бази даних (БД) ІСС, що знижує рівень безпеки всієї системи у цілому;

-    ускладнено супроводження та модифікація тих додатків ІСК, які спілкуються з БД ІСС, оскільки будь-яка зміна схема віддаленої БД на стороні ІСС тягне за собою зміну додатків в ІСК, що ускладнює обслуговування, оновлення чи заміну додатків, встановлених на десятках-сотнях комп’ютерів;

-    значно ускладнюється адміністрування БД ІСС, яке включає в себе управління правами доступу користувачів ІСК.

Істотним недоліком розглянутого сценарію є дублювання додатків ІСС в ІСК, що призводить до неефективного використання ресурсів ІС, що взаємодіють. Зростання популярності глобальної мережі Internet та технології WWW останнім часом викликає підвищений інтерес до них з боку розробників корпоративних ІС. В самому початку WWW створювався як засіб, який надає графічний інтерфейс в Internet і спрощує доступ до інформації, розподіленої по мільйонам комп’ютерів у всьому світі. Основними компонентами були сторінки, вузли, браузери та сервери Web. Користувачам була надана можливість навігації по Internet з використанням технології гіпертексту, підтримуваної протоколами HTTP (Hypertext Transfer Protocol) та стандартом мови HTML (Hypertext Markup Language).

Додаток CGI (Common Gateway Interface) розв’язав проблему обміну інформацією між сервером Web та програмами типу бази даних, які не можуть безпосередньо обмінюватися даними з браузерами Web. В результаті з’явилася можливість реалізації інтерактивної взаємодії кінцевого користувача з програмами сторони Web - серверу, які обробляли інформацію, уведену користувачем в браузері, і в як результат повертали сформовану HTML - сторінку. Багато з існуючих рішень доступні в середовищі Internet і базуються на такому підході.

Поява мови Java надала для розробників ІС абсолютно нові технологічні рішення побудови додатків у середовищі Internet/Intranet. Проте не слід розглядати технологію Java тільки як частину технології WWW, оскільки Java дає змогу розв’язувати задачі більш широкого класу, порівняно з технологіями, які базуються на мові HTML, протоколі HTTP та CGI. Можливості, які надаються WWW - технологією розширили спектр рішень, якими керуються проектувальники при побудові ІС. Проте виникає питання: що собою представляють системи ІС, що взаємодіють, які базуються на технології, чи здатні вони розв’язати проблему ЄІП? Зрозуміло, що це не так. Таке сильне твердження пов’язане з тим, що в процесі розгляду взаємодії інформаційних систем, ІСК з браузером виступає в ролі компоненти зображення, а ІСС з WWW - сервером та додатками виступає як компонента, яка реалізує функціональну логіку та доступ до даних, що відповідає дворівневій архітектурі з інтелектуальним сервером, рис. 4.13. WWW - технологія здатна покращити ситуацію з імпортом/експортом даних між ІСК та ІСС, але є недоліки, що притаманні дворівневій архітектурі з інтелектуальним сервером.

 

Рисунок 4.13 - Архітектура з інтелектуальним сервером

 

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

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

Знання схеми бази даних (БД) необхідно тільки тому додатку, який обробляє дані з цієї БД. Використання ІСС сервісів, які надаються ІС - сервером і реалізують методи обробки даних, дає змогу розв’язати проблему зміни схеми віддаленої бази даних. Статичність інтерфейсів компонентів. які надають ІСС набір сервісів, досягається застосуванням методологій об’єктно-орієнтованого аналізу та проектування, розподілених об’єктних технологій (CORBA, Java, DCOM) на різних етапах створення ІС. Більшість нині використовуваних ІС є додатками до дворівневої архітектури клієнт-сервер. Як засіб спілкування клієнта та сервера часто використовуються неповністю стандартизовані механізми тригерів та збережених процедур. Специфіка їх реалізації, невідокремлена від ядра системи управління БД) призводить до необхідності наявності додаткових обчислювальних ресурсів на стороні сервера.

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

−           не залежить від апаратних та системних програмних засобів;

−           спирається на міжнародні та промислові стандарти;

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

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

−           дає змогу інтегрувати старі додатки (legacy applications) в нові ІЧ;

−           допускає природну інтегрованість створюваних ІС, що гарантує її життєздатність та еволюційний розвиток;

−           дає змогу накопичувати, тиражувати та розвивати формалізовані знання спеціалістів;

−           істотно знижують сумарні витрати на створення ІС/

 

4.7 Технології RMI, CORBA, DCOM

 

Нині виділяють три різні технології, які підтримують концепцію розподілених об’єктних систем. Це технології RMI, CORBA та DCOM.

Архітектура RMI (Remote Method Invocation - виклик віддаленого методу), яка інтегрована JDK1.1, є продуктом компанії Java Soft і реалізує розподілену модель. RMI дає змогу клієнтським та серверним додаткам через мережу викликати методи клієнтів/серверів, які виконуються і Java Virtual Machine. Незважаючи на те, що RMI вважається "легкою" та менш потужною, порівняно з CORBA та DCOM, тим не менше, вона має ряд унікальних можливостей, оскільки розподілене, автоматичне управління об’єктами та можливість пересилати самі об’єкти від машини до машини. На рис. 4.14 зображені основні компоненти архітектури RMI.

 

Модель RMI.

Рисунок 4.14 - Модель RMI

 

Client Stub (перехідник для клієнта) та Server Stub (перехідник для сервера) породжені від одного інтерфейсу, але різниця між ними полягає в тому, що client stub служить для під’єднання до RMI Registry, аserver stub використовується для зв’язку безпосередньо з функціями сервера.

 

4.7.1 Технологія CORBA

Технологія CORBA (Common Object Request Broker Architecture), яка розробляється OMG (Object Management Group) з 1990 року - це архітектура з брокером потрібних спільних об’єктів. На рис. 4.15 наведена основна структура

CORBA 2.0 ORB.

 

ORB (CORBA 2.0).

Рисунок 4.15 - ORB (CORBA 2.0)

 

Dynamic Invocation Interface (DII): надає клієнту змогу знаходити сервери і викликати їх під час роботи системи. IDL Stubsвизначає, яким чином клієнт здійснює виклик сервера. ORB Interfaceспільні для клієнта та для сервера сервіси. IDL Skeleton Interfaceспільні інтерфейси для об’єктів, незалежно від їх типу, які не були визначені в IDL Object Adapterздійснюють комунікаційну взаємодію між об’єктом та ORB.

 

4.7.2 Технологія DCOM

Технологія DCOM (Distributed Component Object Model), рис. 4.16, була розроблена компанією Microsoft як розв’язок для розподілених систем в 1996 р. Нині DCOM є головним конкурентом CORBA, хоч і контролюється нині не Microsoft, а групою TOG (The Open Group), аналогічною OMG. DCOM є розширенням архітектури COM до рівня мережних додатків.

 

 

Архитектура DCOM.

Рисунок 4.16 - Архітектура DCOM

 

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

 

4.8 Переваги та недоліки використання технологій RMI, CORBA, DCOM

 

Переваги та недоліки технології DCOM. Такими є наступні:

Переваги: мовна незалежність; динамічний/статичний виклик; динамічне находження об’єктів; масштабованість; відкритий стандарт (контроль з боку TOG).

Недоліки: складність реалізації; залежність від платформи; немає найменування через URL; немає перевірки безпеки на рівні виконання ActiveX компонент. Крім того DCOM є лише частковим рішенням проблеми розподілених об’єктних систем. Це рішення добре підходить до Microsoft - орієнтованих середовищ. Як тільки в системі виникає необхідність працювати з архітектурою, яка відрізняється від Windows NT та Windows 95, DCOM перестає бути оптимальним рішенням проблеми. Таке положення невдовзі може змінитися, оскільки Microsoft намагається перенести DCOM також на інші платформи. Зокрема, фірмою Software AG вже випущена версія DCOM для Solaris UNIX і планується випуск версій також для інших версій UNIX. Але нині DCOM є задовільним рішенням лише для систем, орієнтованих виключно на продукти Microsoft. Нарікання викликає також невирішеність питання безпеки за умови виконання ActiveX компонент, що може призвести до неприємних наслідків.

Переваги та недоліки технології RMI. Такими є наступні:

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

Недоліки: підтримка тільки однієї мови - Java; свій власний, не IIOP - сумісний протокол взаємодії; труднощі інтегрування з існуючими додатками; погана масштабованість. Завдяки своїй Java - моделі, яка є легко використовуваною, RMI є самим простим і самим швидким способом створення розподілених систем. RMI є добрим вибором для створення RAD - компонент та невеликих додатків на мові Java. Технологія RMIне є такою потужною, як DCOM чи CORBA, зокрема RMI використовує свій (не CORBA/ IIOP) сумісний протокол передачі JRMP і може взаємодіяти лише з іншими Java об’єктами. Підтримка тільки однієї мови робить неможливою взаємодію з об’єктами, написаними не на мові Java. Тим самим, роль RMI у створенні великих, масштабованих промислових систем, знижується.

Переваги та недоліки технології CORBA. Такими є наступні:

Переваги: платформна незалежність; мовна незалежність; динамічні виклики; динамічне виявлення об’єктів; можливість масштабування; CORBA-сервіси; широка індустріальна підтримка.

Недоліки: відсутність передачі параметрів "за значенням"; відсутність динамічного завантаження компонент - перехідників; відсутність найменування через URL. До основних переваг CORBA можна віднести міжмовну ті міжплатформенну підтримку. Незважаючи те, що CORBA - сервіси віднесені до переваг технології CORBA, їх в рівній мірі можна одночасно віднести до недоліків CORBA, внаслідок повної відсутності їх реалізації.

Технологія CORBA відноситься до найефективніших, сучасних, придатних для крупних проектів, це технологія розподілених об’єктів. Причиною цього є те, що обидві технології CORBA та DCOM надзвичайно схожі за своєю функціональністю та за своїми можливостями (багатомовна підтримка, динамічний виклик, масштабованість та ін.) у DCOM відсутній важливий критичний елемент - мультиплатформна підтримка. Одного факту, що нині DCOM не підтримує цілком міжплатформну переносимість, достатньо, щоб не розглядати її як повноцінне, закінчене рішення. Крім того. в той час, як до складу OMG вже нині входять більше 700 членів (компаній - виробників програмних продуктів, комп’ютерів, телекомунікаційних систем, розробників прикладних систем та кінцевих користувачів), і практично будь-яка специфікація, розроблена цим консорціумом, фактично стає стандартом, технологія DCOM лише недавно став переходити від Microsoft до аналогічної OMG організації - групи TOG (The Open Group). Ще один плюс технології CORBA такий. Коло виробників продуктів, які підтримують дану технологію, ширше, порівняно аналогічного кола DCOM. Тобто виявляється, що саме CORBA є технологією, яка повністю призначена для промислових, відкритих, розподілених об’єктних систем.

 

4.9 Технологія CORBA

 

Наприкінці 1980 - х і на початку 1990 - х років багато провідних фірм - розробників займалися пошуком технологій, які принесли б відчутну користь на мінливому ринку комп’ютерних розробок. Такою технологією виявилася область розподілених комп’ютерних систем. Необхідно було розробити єдину структуру, яка б дала змогу здійснити повторне використання та інтеграцію коду, що важливо для розробників. Ціна за повторне використання коду та інтеграцію коду була високою, проте ніхто з розробників поодинці не міг втілити в реальність широко використовуваний, мовно-незалежний стандарт, який включає в себе підтримку складних багато зв'язних додатків. У травні 1989 р. була сформована OMG (Object Management Group). Нині OMG нараховує більше 700 членів (до OMG входять практично всі найбільші виробники програмного забезпечення (ПЗ), за виключенням Microsoft). Задачею консорціуму OMG є визначення набору специфікацій, які дають змогу будувати інтероперабельні інформаційні системи. Специфікація OMG - The Common ObjectRequest Broker Architecture (CORBA) є індустріальним стандартом, який описує високо рівневі засоби підтримки взаємодії об’єктів в розподілених гетерогенних середовищах. CORBA специфікує інфраструктуру взаємодії компонент (об’єктів) на представницькому рівні і на рівні додатків моделі OSI. Вона дає розглядати всі додатки в розподіленій системі як об’єкти. причому об’єкти можуть одночасно відігравати роль клієнта та сервера: роль клієнта, якщо об’єкт є ініціатором виклику на ньому який-небудь метод. Об’єкти-сервери зазвичай називають "реалізацією об’єктів". Практика показує, що більшість об’єктів одночасно виконують роль клієнтів і серверів, по черзі викликаючи методи на інших об’єктах і відповідаючи на виклику ззовні. Використовуючи CORBA, тим самим , є можливість будувати більш гнучкі системи, ніж системи клієнт-сервер, основані на дворівневій і трирівневій архітектурі.

Мова OMG IDL (Interface Definition Language - Мова Опису Інтерфейсу) представляє собою технологічно незалежний синтаксис для опису інтерфейсу об’єктів. При описі програмної архітектури, OMG IDLдобре використовується як універсальна нотація для окреслювання границь об’єкту, які визначають його поведінку у відношенні до інших компонентів ІС. OMG IDL дає змогу описати інтерфейси, які мають різні методи та атрибути. Мова також підтримує дослідження інтерфейсів, що необхідно для повторного використання об’єктів з можливістю їх розширення чи конкретизації. IDL є чисто декларативною мовою, тобто вона не містить ніякої реалізації. IDL - специфікації можуть бути відкомпільовані (відображені) в заголовкові файли та спеціальні прототипи серверів, які можуть використовуватися безпосередньо програмістом. Тобто IDL - визначені методи можуть бути написані, і далі виконані, на будь-якій мові, для якої існує відображення з IDL. До таких мов відносяться С, С++, SmallTalk, Java та Ada.

 

Рисунок 4.17 - CORBA IDL відображення в моделі Клієнт/Сервер

 

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

 

Лістинг 4.1 – Структура CORBA IDL файлу

module <identifier> {
<type declarations>;
<constant declarations>;
<exception declarations>;
interface <identifier> [:<inheritance>] {
<type declarations>;
<constant declarations>;
<attribute declarations>;
<exception declarations>;
[<op_type>]<identifier>(<parameters>)
[raises exception] [context]
.
.
[<op_type>]<identifier>(<parameters>)
[raises exception] [context]
.
.
}
interface <identifier> [:<inheritance>]
.
.
}

 

Репозитарій Інтерфейсів (Interface Repository), який містить означення інтерфейсів на IDL, дає змогу бачити інтерфейси доступних серверів в мережі і програмувати їх використання в програмах-клієнтах.

Object Management Architecture. Восени 1990 р. OMG вперше опублікувала документ Object Management Architecture Guide (OMA Guide). Він був відкоригований у вересні 1992 р. Деталі Common Facilities(Спільні засоби) були добавлені в січні 1995 р. На рис. 4.18 показані чотири основні елементи цієї архітектури:

 

OMG's Object Management Architecture

Рисунок 4.18 - OMG’s Object Management Architecture

 

1.  Object Request Broker визначає об’єктну шину CORBA.

2.  Common Object Services представляють собою колекцію служб, споряджених об’єктивними інтерфейсами, які забезпечують підтримку базових функцій об’єктів.

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

4.  Application Objects - це прикладні бізнес-об’єкти і додатки, які є основними споживачами всієї CORBA інфраструктури.

ORB, Object Request Broker (брокер об’єктних запитів) - це об’єктна шина, яка дає змогу об’єктам напряму виробляти і відповідати на запити інших об’єктів, розташованих як локально (на одному комп’ютері, але в різних процесах), так і віддалено. Клієнта не цікавлять комунікаційні та інші механізми, з використанням яких відбувається взаємодія між об’єктами, виклик і збереження серверних компонентів. CORBA - специфікації зачіпають лише IDL, відображення в інші мови, APIs для взаємодії з CORBA та сервіси, які надаються ORB. CORBA ORB не надає широкого набору розподілених middleware (проміжних) послуг. ШинаORB дає змогу об’єктам знаходити один другого прямо в процесі роботи і викликати один у другого різноманітні служби. Вона є набагато тоншою системою, порівняно з іншими клієнт/сервер middleware - системами, такими, як RPC (Remote Procedure Calls) чи MOM (Message-Oriented Middleware).

Шлях від RPC до ORBСтосовно відмінності механізму викликів CORBA та RPC можна сказати наступне. Ці механізми схожі, але між ними є серйозні відмінності. З використанням RPC можна викликати певну функцію, а з використанням ORB можна викликати метод у певного об’єкта. Різні об’єкти класів можуть по-різному відповідати на виклик одного і того ж методу. Оскільки кожний об’єкт управляє своєю власною (на додаток - особистою) інформацією, то метод буде викликаний на сугубо конкретних даних. У випадку RPC, буде виконана лише якась конкретна частина коду сервера, яка і взаємодіє з даними сервера. Всі функції з однаковими іменами будуть виконані абсолютно однаково. В RPC відсутня конкретизація викликів, в тому розумінні, в якому це відбувається в ORB. В ORB всі виклики функцій здійснюються до конкретних об’єктів, тим самим, результати цих функцій можуть бути абсолютно різними. Виклики функцій обробляються в специфічній для кожного окремого об’єкта формі.

Переваги ORB. Теоретично CORBA визначається як краща клієнт/сервер middleware - система, але на практиці вона задовільна лише настільки, наскільки задовільні продукти, що її реалізують. До основних комерційних ORB відносяться Orbix від фірми IONA Technologies; DSOM від IBM; Object Broker від Digital; JOE від Sun; Visibroker від Visigenic та Netscape; ORB+ від HP. Переваги кожної CORBA ORB такі:

-    Статистичні та динамічні виклики методів. CORBA ORB надає можливість або статично визначити виклики методів прямо під час компіляції, або знаходити їх динамічно, але вже під час роботи програми.

-    Відображення та мови високого рівня. CORBA ORB дає змогу викликати методи у серверних компонент,використовуючи будь-який з певного списку мов високого рівня - С, С++, SmallTalk, Java, Ada.Абсолютно неважливо, на якій мові написані об’єкти. CORBA відділяє інтерфейси від реалізації і надає мово незалежні типи даних, що дає змогу здійснювати виклик методів, минаючи границі якоїсь мови програмування та конкретної операційної системи.

-    - Система, що само описується. З використанням своїх метаданих, CORBA дає змогу описувати інтерфейс будь-якого сервера, відомого системі. Кожна CORBA ORB повинна підтримувати Репозитарій Інтерфейсів, який зберігає необхідну інформацію, яка описує синтаксис інтерфейсів, підтримуваних серверами. В своїй роботі клієнти використовують ці метадані для здійснення викликів до серверів.

-    - Прозорість. ORB може виконуватися як сам собою (наприклад, на портативному комп’ютері), оскільки в оточенні всіх інших ORB, з якими вона взаємодіє шляхом CORBA 2.0 ІІОР (Internet Inter- ORB Protocol) протоколу. ORB може здійснювати між об’єктну взаємодію також для одного процесу, як і для кількох процесів, які виконуються на одній машині, та для процесів , виконання яких відбувається в мережі, під різними операційними системами. Реалізація цих взаємодій ніяк не зачіпає самі об’єкти. При використанні технології CORBA, розробник не має турбуватися про розташування серверів, запуск (активування) об’єктів, вирівнювання розміру змінних в залежності від платформи та операційної системи, та про те, як здійснюється передача повідомлень. Рішення всіх цих задач бере на себе продукт, який підтримує стандарт CORBA.

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

-    Поліморфізм при виклику методів. ORB не просто викликає віддалений метод - ORB викликає метод на віддаленому об’єкті. Тобто виконання одних і тих же функцій на різних об’єктах призведуть до різних дій, в залежності від типу об’єкта.

Object Services. CORBA Object Services представляє собою набір сервісів системного рівня, які зображуються у вигляді компонентів з певними визначеними IDL - інтерфейсами. Ці компоненти доповнюють функціональність ORB, їх можна використати для створення, іменування компонентів, та ін. Нині OMG визначає 14 стандартних сервісів. Практично всі комерційні ORB не підтримують жодного із сервісів, і тільки небагато з них (Visibroker) - тільки один, два.

Common Facilities. Common Facilities (спільні засоби) заповнюють простір між ORB та об’єктивними службами з одного боку, та прикладними службами, з іншої. Тобто ORB забезпечує базову інфраструктуру,Object Services - фундаментальні об’єктивні інтерфейси, а задача Common Facilities - підтримка інтерфейсів сервісів високого рівня, які можуть включати спеціалізацію Object Services. Тобто операції, представленіCommon Facilities, призначені, зокрема, для використання Object Services та прикладними об’єктами. Це реалізується шляхом наслідування стандартних Інтерфейсів. Спільні засоби поділяються на горизонтальні та вертикальні. До горизонтальних сервісів відносяться такі спільні сервіси, як, наприклад, управління інформацією, задачами, всією системою, тобто засоби, які не залежать від конкретних прикладних систем. До вертикальних сервісів відносяться сервіси, специфічні для якоїсь діяльності, наприклад, медицина, фінанси.

Application Objects. Об’єкти, якщо вони приймають участь в обміні з ORB з використанням IDL. Як правило, додатки складаються з кількох бізнес-об’єктів, що взаємодіють. Додатки-об’єкти будуються поверхORB, які надаються ORB, Common Facilities та Object Facilities сервісів. Сутність для замовників (або системних інтеграторів) полягає в тому, щоб зібрати різні бізнес-об’єкти до одної системи, причому, поза залежністю від виробника.

CORBA та WWW. Відповідь на поставлене раніше питання - як об’єднати ІС, засновані на технології WWW, з іншими (в тому числі розподілені) ІС - полягає в наступному: слід пов’язати технологію розподілених об’єктів (тобто технологію CORBA) з технологією WWW. Метою такої роботи є детальний розгляд зв’язки CORBA та WWW. Питання впровадження CORBA в ІС виходить за рамки курсу. Є два рішення такої задачі, перше - будується на застосуванні технології CGI, а друге - на застосуванні технології Java. Досліджено практичне застосування цих технологій, з використанням продуктів Orbix та OrbixWeb від IONA Technologies.

CORBA - CGI. В чистому вигляді, технологія CGI полягає в наступному: для формування HTML - сторінки WEB - сервер запускає деякий CGI - скрипт, який може реалізувати достатньо складну функціональну логіку і звертатися, наприклад, до бази даних. CGI - скрипт представляє собою окремий виконуваний додаток і мова, на якій написаний скрипт, не відіграє великої ролі. Рішення CORBA- CGI, рис.4.19, базується на тому, що CGI - скрипт є одночасно однією з компонент розподіленої системи. Головна відмінність від технології CGI полягає в тому, що CGI - скрипт є не просто виконуваним модулем, а він є одночасно і CORBA - клієнтом. В певному смислі, скрипт служить точкою входу і виходу в розподіленій системі, усередині якої можуть відбуватися різноманітні процеси.

 

Рисунок 4.19 - CGI та CORBA

 

До переваг цієї технології можна віднести практично всі переваги використання CORBA. Крім того, користувач працює із звичними для нього HTML - сторінками, що особливо важливо при роботі з об’ємною текстовою інформацією. Стосовно недоліків цієї технології, практика свідчить, що це невелика ефективність системи. Кожного разу при пере завантаженні сторінки слід заново виконувати CGI - скрипт, заново встановлювати з’єднання з іншими компонентами системи. Це неефективно, що особливо виявляється, коли система одночасно використовується кількома користувачами. З іншого боку, не жертвуючи ефективністю, неможливо своєчасно повідомляти користувача про зміни, які відбулися в інформації, яка ним проглядається. Вони будуть помітними лише за умови пере завантаження сторінки. Тобто користувач приймає участь в системі виключно в ролі клієнта. Окремим рішенням проблеми ефективності виконання CGI - запитів (особливо в багатокористувацькій системі), може бути розширення функціональності використовуваного WEB - сервера, шляхом добавлення до нього відповідних функцій. В цьому напрямку здійснена робота з вбудовуванню до WEB - сервера Apache (платформи SunOS, Windows NT) підтримки звернення до Orbix ORB. Складності також виникають в разі створення, складних гілкуватих користувацьких інтерфейсів. Справа в тому, що в системі, за умови виконання запитів окрім введеної у вікно браузера інформації, необхідна додаткова, скрита від користувача, яка характеризує поточний стан система інформація. Вся інтерфейсна частина системи прив’язана до вікна браузера, а та, яка виводиться на екран інформація створюється динамічно в залежності від параметрів запиту та внутрішнього стану інформаційної системи на певний момент часу. Внаслідок цього, якщо користувач виконує неконтрольовану навігацію вперед-назад за сторінками, що проглядаються, підвищується ризик десинхронізації інформації, яка проглядається користувачем і зберігається на сервері, що не є припустимим. Більше того, система повинна слідкувати і за тим, щоб вільні переходи від сторінки до сторінки мали б логічний смисл, що важливо. Тим самим, у випадках складних користувацьких інтерфейсів необхідна наявність жорсткого контролю за поточним станом ІС.

Java-CORBA. Друге рішення проблеми зв’язування технологій CORBA та WWW - мова Java, рис. 4.20. Справа в тому, що OMG стандартизувала відображення з IDL в Java. Є програмні продукти, які реалізують зв’язок CORBA та Java - наприклад, Java Virtual Machine (JVM), всередині якої і виконується завантажений аплет.

 

Рисунок 4.20 - Java та CORBA

 

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

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

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

Java - шлях до синхронізації інформації. В разі використання технології Java - CORBA, Java - аплети можуть відігравати роль клієнтів та серверів. Це дає змогу створювати "живі" сторінки - інформація на яких змінюється практично постійно. Наприклад, якщо аплет представляє собою відображення стану певного пристрою, то за умови переходу пристроїв з одного стану до іншого, інформація в аплеті практично миттєво зміниться відповідним чином. Причому це може бути інформація будь-якого типу - графічна чи текстова. Тоді виникає питання: яким способом відбувається обмін інформацією між аплетами та іншою частиною системи?

В CORBA існують два різних типи передачі повідомлень - механізм PUSH та механізм PULL .

Механізми PUSH та PULL. Механізм PULL, рис. 4.21, представляє собою наступне: коли клієнт готовий обробляти повідомлення, він опитує сервер на наявність у нього нових повідомлень. Якщо таких немає, то клієнт через певний проміжок часу повторює операцію. В залежності від контексту розв’язуваної задачі та пропускних здатностей мережних каналів, тип взаємодії клієнта та сервера може бути асинхронним та синхронним. Механізм PUSH, в певному розумінні, протилежний механізму PULL. В цьому випадку сервер повідомлень сам, у міру надходження нових повідомлень, буде інформувати про це клієнтів. Тобто клієнти самі є серверами, а сервер повідомлень лише викликає в них відповідні методи, "вштовхуючи" їм повідомлення. Як і в моделі PULL, взаємодія клієнта та сервера повідомлень може бути асинхронною та синхронною.

 

Рисунок 4.21 - Механізми PULL та PUSH

 

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

В моделі PUSH сервер повідомлень завантажений помітно менше. Сервер звільнений від необхідності регулярно реагувати на виклики клієнтів, які очікують. Тепер він взаємодіє з клієнтами-слухачами. "Виштовхування" повідомлень клієнту застосовується особливо в тих випадках, коли повідомлення, які з’явилися на сервері повідомлень, повинні бути негайно оброблені клієнтом (клієнтами). За наявності неякісного зв’язку між вузлами, механізм PUSH набагато більше рентабельний, порівняно з PULL - він використовує канал лише один раз для кожного клієнта. За умови реальних розробок ІС, мають місце обидва представлених способи взаємодії компонентів. Розумна комбінація компонент ІС, які підтримують PUSH/ PULL моделі обміну повідомленнями, дає змогу досягнути високого рівня гнучкості та продуктивності створюваної ІС.

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

Застосування технологій Java-CORBA та CORBA-CGI. Практика свідчить, що технологія Java-CORBA краще за все підходить для створення WWW CORBA-клієнтів, які: мають нестандартний, або не HTML - подібний користувацький інтерфейс; активно взаємодіє з іншими компонентами ІС протягом часу; повинні приймати участь в системі в ролі клієнта, та в ролі сервера. Технологію CORBA-CGI вигідно застосовувати у випадку, якщо: відбувається робота з великими обсягами текстової інформації; системні ресурси на стороні клієнта малопотужні. Незважаючи на те, що переваги технології Java-CORBA над технологією CORBA-CGIзначні, і область застосування ширша, обидві розглянуті технології добре підходять для об’єднання WWW - систем та клієнт/сервер - систем. Технологія CORBA-CGI розширює можливості CGI, а технологія Java-CORBA можливості всього WWW - до рівня розподілених об’єктних систем.

Тобто нині технології Java та CORBA добре доповнюють одна іншу як потужний і універсальний засіб для захисту проблеми об’єднання систем, які базуються на технології WWW, з подібними та іншими, особливо розподіленими, ІС. Проте з’являється нова технологія DCOM (Microsoft), яка сильно потіснила CORBA з ринку Windows - орієнтованих систем. Технологія RMI, навпаки, робить кроки назустріч CORBA. Починаючи з JDK 1.2, протокол RMI буде виконуватися поверх протоколу IIOP, що вигідно Java та CORBA розробникам. Масове використання технології Java-CORBA виведе Internet на новий рівень взаємодії. В такий спосіб відбудеться перехід від Web до нової, об’єктної мережі – Object Web.

Лекція 5 Безпека файлової системи. Сертифікат відкритих ключів

 

5.1 Основні положення

 

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

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

-    Центр Сертифікації (Certificate Authority – CA) – спеціальна організація, що володіє повноваженнями видавати (підписувати) цифрові сертифікати. Різні CA зазвичай незалежні між собою. Відносини між CA і його клієнтами регулюються спеціальним документом.

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

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

-    У GSI використовуються два типи сертифікатів X.509:

-    Сертифікат користувача (User Certificate) – цей сертифікат повинен мати кожен користувач, що працює з GRID-системою. Сертифікат користувача містить інформацію про ім'я користувача, організацію, до якої він належить, і центр сертифікації, що видав даний сертифікат.

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

 

5.2. Вимоги безпеки

 

GRID пред'являє ряд вимог по безпеці, деякі з них приведені нижче.

Множинні інфраструктури безпеки

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

Системи безпеки периметру

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

Ідентифікація, авторизація і аккоунтинг

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

Шифрування

ІТ інфраструктура і її управління вимагає шифрування комунікацій, принаймні найосновніших.

 

Firewall’и мережевого рівня і додатку

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

Сертифікація

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

 

5.3 Інфраструктура захисту Grid (GSI)

 

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

 

5.3.1 Фундаментальні поняття захисту

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

-    Практическая Криптография. Bruce Schneier. John Wiley & Sons, 2003. http://www.schneier.com/book-practical.html

-              Прикладная Криптография. Bruce Schneier. John Wiley & Sons, 1996. http://www.schneier.com/book-applied.html

5.3.1.1 Безпечна комунікація

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

Три ключові елементи безпечної комунікації

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

Примітка: Існують книги і URL, які також говорять про “незречення” (non-repudiation), особливість яку деякі автори розглядають як четвертий ключовий елемент безпечних діалогів. “Незречення” не описується в літературі тому, що більшість авторів прагнуть просто вважати це частиною аутентифікації і в цьому документі ця характеристика не буде розглянута.

Конфіденційність

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

Наприклад, припустимо, що потрібно передати повідомлення “INVOKE METHOD ADD”, і необхідна упевненість, що якщо третя сторона перехопить це повідомлення (наприклад, використовуючи мережевийсніфер), вона не зможуть його розібрати. Можна використовувати звичайний алгоритм кодування, який просто змінює кожну букву на наступну в алфавіті. Кодоване повідомлення було б “JOWPLFANFUIPEABEE” (припустимо, що “A” слідує після символу пропуск). Якби третя сторона знала використовуваний алгоритм кодування, повідомлення не мало б сенсу. З іншого боку одержуюча сторона знала б алгоритм розшифровкизаздалегідь (змінивши кожну букву на попередню в алфавіті) і тому могла розібрати повідомлення. Звичайно, цей метод тривіальний, і в даний час алгоритми кодування набагато більш ускладнені. Деякі з таких алгоритмів будуть розглянуті нижче.

Цілісність

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

Традиційні алгоритми кодування не захищають від такого роду атак. Наприклад, розглянемо простій алгоритм, який був запропонований вище. Якщо третя сторона використовувала мережевий сніфер, щоб змінити кодоване повідомлення на “JAMJAMJAMJAMJAMJA”, одержуюча сторона використовувала б алгоритм розшифровки і отримала повідомлення “I LI LI LI LI LI “. Хоча атакуюча сторона, можливо, не мала б ніякого поняття, що повідомлення містить, але, проте, могла змінити його (відносно просто для деяких мережевих інструментів сніферів). Так легко ввести в оману одержуючу сторону, яка могла б сприйняти це як помилку в комунікації. Алгоритми криптографії загального ключа (буде коротко розглянутий далі) захищають від видів нападів (одержуюча сторона має спосіб дізнатися, якщо отримане повідомлення послане передавальною стороною і, таким чином, не було змінено).

Аутентифікація

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

5.3.1.2 Авторизація

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

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

5.3.1.3 Авторизація порівняно з Аутентифікацією

Сплутати аутентифікацію і авторизацію дуже просто, не стільки, тому, що вони зв'язані (загалом, потрібно виконувати аутентифікацію користувача, щоб ухвалити авторизаційне рішення про цього користувача), а через те, що вони звучать однаково (auth...ation). Це частково погіршено фактом, що багато людей прагне скоротити обидва слова як “auth” (особливо в програмному коді). Хоч вони є відмінними поняттями їх досить часто зіставляють. І якщо є сумніви, важливо пам'ятати, що аутентифікація посилається на з'ясування достовірності чиєї-небудь особи (якщо вона дійсно та що потрібна) і що авторизаціязвертається до з'ясування того, хто авторизований виконувати певне завдання.

5.3.1.4 Введення в криптографію

Криптографія – “мистецтво запису в секретних символах”. Кодування – дія перекладу нормального повідомлення в повідомлення, записане з “секретними символами” (також відоме як кодоване повідомлення).

Розшифровка – дія перекладу повідомлення, записаного з “секретними символами” в читане повідомлення (розкодоване повідомлення). Криптографія, безумовно, одна з найголовніших областей в захисті даних комп'ютера, оскільки сучасні алгоритми кодування можуть гарантувати всі три елементи безпечного діалогу: конфіденційність, цілісність, і аутентифікацію.

Алгоритми засновані на ключі

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

Алгоритм заснований на ключі використовує ключ кодування, щоб кодувати повідомлення. Це означає, що кодоване повідомлення генерується, використовуючи не тільки повідомлення, але і, використовуючи “ключ” (Рисунок 5.1)

 

Рисунок 5.1 – Кодування засноване на ключі

 

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

 

Рисунок 5.2 – Розшифровування заснована на ключі

 

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

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

 

1 2 3 4 5 6 5 4 3 2 1

 

Виберемо ключ, який використовуватиметься для кодування повідомлення. Імовірно ключ буде “4232”. Щоб кодувати повідомлення потрібно буде повторювати ключ, стільки скільки необхідно, для “покриття” цілого повідомлення:

 

1 2 3 4 5 6 5 4 3 2 1

4 2 3 2 4 2 3 2 4 2 3

 

Кодування повідомлення з додаванням обох номерів:

 

1 2 3 4 5 6 5 4 3 2 1

+ 4 2 3 2 4 2 3 2 4 2 3

-----------------------

5 4 6 6 9 8 8 6 7 4 4

 

Результуюче повідомлення (54669886744) – закодоване повідомлення. Повідомлення може бути розшифровано слідуючи зворотному процесу: повторюючи ключ, стільки раз скільки потрібно, щоб покрити повідомлення, а потім відняти кожен з символів ключа:

 

5 4 6 6 9 8 8 6 7 4 4

- 4 2 3 2 4 2 3 2 4 2 3

-----------------------

1 2 3 4 5 6 5 4 3 2 1

 

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

Слід зазначити, що це дуже тривіальний приклад. Поточні алгоритми, засновані на ключі, набагато складніші (ключі набагато довші, і процес кодування не такий простий, як “додавання повідомлення і ключа”). Проте ці складні алгоритми засновані на тому ж основному принципі, показаному в нашому прикладі: ключ потрібний, щоб кодувати/розшифрувати повідомлення.

Симетричні і асиметричні алгоритми, засновані на ключі

Алгоритм прикладу підпадає в категорію симетричних алгоритмів. Цей тип алгоритму використовує один ключ для кодування і розшифровки (Рисунок 5.3).

 

Рисунок 5.3 – Симетричний алгоритм, заснований на ключі

 

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

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

Криптографія загального ключа

Алгоритми загального ключа – асиметричні алгоритми і, тому, засновані на використанні двох різних ключів, замість одного. У криптографії загального ключа, ключі називають приватний ключ і загальний ключ

-    Приватний ключ: Цей ключ повинен знати тільки його власник.

-    Загальний ключ: Цей ключ відомий кожному (він загальний).

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

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

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

 

Рисунок 5.4 – Асиметричний алгоритм заснований на ключі

 

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

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

 

Рисунок 5.5 – Генерація загального ключа

 

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

Основний недолік використання систем з відкритим ключем в тому, що вони не так швидкі як симетричні алгоритми.

5.3.1.5 Цифрові підписи: Цілісність в системах з відкритим ключем

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

 

Рисунок 5.6 – Цифровий підпис

 

Цифровий підпис для повідомлення генерується на двох етапах:

-    Генерується Резюме повідомлення. Резюме повідомлення – короткий звіт передаваного повідомлення, має дві важливі властивості: (1) Він завжди менший, ніж повідомлення безпосередньо (2) Навіть найлегша зміна в повідомленні проводить різне резюме. Резюме повідомлення генерується з використанням безлічі алгоритмів хешування.

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

Цифровий підпис прикріпляється до повідомлення, і відправляється одержувачеві. Одержувач потім виконує наступне:

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

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

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

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

5.3.1.6 Аутентифікація в системах із загальним ключем

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

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

5.3.1.7 Сертифікати і центри сертифікації (CA)

Цифровий сертифікат – це цифровий документ, який засвідчує, що певний загальний ключ належить конкретному користувачеві. Сертифікат підписує третя сторона іменована центр сертифікації (або CA). Рисунок 5.7 ілюструє, що є цифровим свідоцтвом.

 

Рисунок 5.7 – Цифровий сертифікат

 

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

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

5.3.1.8 Довіра

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

Проте все це вірно, якщо ви довіряєте сертифікату. Щоб бути точніше, вам доведеться довіряти CA який підписує сертифікат. Немає ніяких хитромудрих алгоритмів, щоб вирішити, коли CA надійний, ви повинні вирішити для себе, довіряєте ви CA чи ні. Це означає, що використовувана система з відкритим ключем буде, загалом, мати список “довірених CA”, який включає цифрові сертифікати довірених CA (кожен сертифікат, у свою чергу, містить загальний ключ CA для перевірки цифрового підпису).

Потрібно буде вирішити який CA включити в цей список. Деякі CA добре відомі і їх включають за умовчанням в багатьох системах із загальним ключем (наприклад, веб-навігатори зазвичай включають VeriSign(http://www.verisign.com) і GlobalSign (http://www.globalsign.com) сертифікати, тому що багато веб-вузлів використовують сертифікати, випущені цими компаніями. Звичайно, є можливість додати і інший CA до “Довіреного списку”. Наприклад, якщо ваш відділ встановлює CA, і ви довіряєте, що CA відділ видаватиме свідоцтва тільки надійним людям, тому ви можете додати його до списку.

5.3.1.9 Формат сертифікату X.509

Тепер, коли ми розглянули основи безпеки перейдемо до формату, в якому кодуються цифрові сертифікати: формат сертифікату X.509. Сертифікат X.509 – це простій текстовий файл, який включає багато інформації в самому специфічному синтаксисі. Цей синтаксис поза компетенцією даного документа, нижче перераховані чотири найбільш важливі речі, які можна виявити в сертифікаті X.509:

-    Суб'єкт: Це ім'я користувача. Воно кодується як видатне ім'я (формат для різних імен буде пояснений далі).

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

-    Запрошуюча сторона: видатне ім'я CA.

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

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

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

5.3.1.10 Видатні імена

Імена в сертифікатах X.509 не кодуються просто як “загальні імена”, як наприклад “Borja Sotomayor, “Lisa Childers”, “Центр сертифікації XYZ”, або “Системний Адміністратор”. Вони кодуються, як видатні імена, які є списком пар значення імені відокремленими комою. Розглянемо приклад з видатними іменами:

O=University of Chicago, OU=Department of Computer Science, CN=Borja Sotomayor

O=Argonne National Laboratory, OU=Mathematics and Computer Science Division, CN=Lisa Childers

Що означають “O”, “OU”, і “CN”? Видатне ім'я може мати декілька різних атрибутів, ось основні з них:

-    O : Організація

-    OU : Організаційний Підрозділ

-    CN : Загальне Ім'я (загалом, ім'я користувача)

-    C : Країна

5.3.1.11 Ієрархії CA

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

 

Рисунок 5.8 – Ланцюг перевірки сертифікату

 

На малюнку сертифікат Borja підписує центр сертифікації FOO. Сертифікат центру сертифікації FOO, у свою чергу, підписується центром сертифікації BAR. Нарешті, сертифікат BAR підписує сам себе.

Якщо ви отримуєте сертифікат Borja, і явно не довіряєте CA FOO (запрошуюча сторона сертифікату), це не означає, що сертифікат не надійний. Ви, можливо, перевірили б, що сертифікат CA FOO випустив CA, якому ви довіряєте. Якщо з'ясується що CA BAR знаходиться у вашому “довіреному списку”, це означатиме, що свідоцтво Borja надійно.

Проте зверніть увагу, що CA (BAR) вищого рівня підписав свій власний сертифікат. Це цілком нормально, і називається само-підписаним сертифікатом. CA з само-підписаним сертифікатом називаєтьсякореневий CA, тому що немає нікого вище. Щоб довірити сертифікату, підписаному цим CA, він повинен обов'язково бути у вашому “довіреному списку” CA.

 

5.3.2 Введення в GSI

Інфраструктура Grid є основою для рівня захисту GT4. Захист – одна з найголовніших частин додатку Grid. Оскільки grid має на увазі перетин меж організації, ресурси стають доступними для інших організацій. Це формулює багато вимог:

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

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

Залежно від додатку, можливо, також є зацікавленість в цілісності даних і конфіденційності, хоча в grid- застосуванні це, загалом, не так важливо як аутентифікація.

Інструментарій Globus 4 дозволяє долати проблеми захисту, сформульовані grid-додатками через Інфраструктуру Захисту Grid (або GSI). GSI складається з набору інструментів командного рядка для управління сертифікатами, і безліччю класів Java для легкого об'єднання захисту у веб-службах. GSI пропонує програмістам наступні характеристики:

-    Захист транспортного рівня і рівня повідомлень;

-    Аутентифікація через цифрові сертифікати X.509;

-    Різні схеми авторизації;

-    Делегація посвідчення особи і єдиний вхід (sign-on);

-    Різні рівні захисту: контейнер, обслуговування, і ресурс

5.3.2.1 Захист транспортного рівня і рівня повідомлень

Транспортний рівень використовує TLS – Transport Layer Security (SSL – Secure Sockets Layer). Рівень повідомлень має дві реалізації, засновані на різних стандартах: WSSecurity і WS-SecureConversation. При встановленні з'єднання по WS-SecureConversation визначається, так званий, контекст безпеки (secure context). Після ініціалізації обміну повідомленнями всі подальші повідомлення використовують цей контекст безпеки. Крім того, на відміну від WS-Security, WS-SecureConversation забезпечує анонімну аутентифікацію і делегування має рацію.

GSI дозволяє розвернути захист на двох рівнях: транспортний рівень або рівень повідомлень. Відмінності між цими рівнями: припустимо необхідно, щоб комунікація була приватною. Якщо використовуєтьсязахист транспортного рівня, як показано на Рисунку 5.9, у такому разі всі комунікації (вся інформація між клієнтом і сервером) кодувалася б. Якщо використовується захист для рівня повідомлень, як показано на Рисунку 5.10, в цьому випадку кодується тільки вміст повідомлення SOAP, а решта частини повідомлення SOAP не кодується.

 

 

Рисунок 5.9 Захист транспортного рівня

 

 

Рисунок 5.10 – Захист рівня повідомлень

 

Як транспортний рівень, так і захист рівня повідомлень в GSI засновані на криптографії “відкритого ключа” (public-key) і, тому, може гарантувати конфіденційність, цілісність, і аутентифікацію. Проте не всім зв'язкам буде потрібно всі три характеристики. Взагалі, безпечний діалог GSI повинен як мінімум бути засвідчений. Цілісність бажана зазвичай, але може бути відключена. Кодування також може бути активізоване, щоб гарантувати конфіденційність.

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

GSI пропонує дві схеми захисту рівня повідомлень, і одна схема для транспортного. Відмінності між ними представлені в таблиці.№3.

-    Безпечне Повідомлення GSI: Забезпечує захист рівня повідомлень і засновано на запропонованому стандарті WS-Security.

-    Безпечний Діалог GSI: Забезпечує захист рівня повідомлень і заснований на специфікації WS-SecureConversation. Якщо вибраний цей метод, встановлюється контекст безпеки (secure context) між клієнтом і сервером. Після початкового обміну повідомленнями, щоб встановити контекст, всі наступні повідомлення зможуть використовувати цей контекст багато разів, що приводить до кращої роботи, чим Безпечне Повідомлення GSI (якщо верх установки контексту прийнятний). До того ж, Безпечний Діалог GSI – це схема, яка підтримує тільки делегацію посвідчення особи.

-    Транспорт GSI: Забезпечує захист транспортного рівня, використовуючи TLS – захист транспортного рівня (раніше відомий як SSL) і забезпечує кращу роботувикористовується за умовчанням в GT4. TLS і SSL – спеціальні протоколи для створення захищеного каналу між двома сторонами, що зв'язуються, що забезпечують постійне шифрування передаваної інформації і, якщо потрібно, аутентифікацію протягом одного сеансу.

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

 

Таблица 5.1 – Порівняння захисту транспортного рівня і рівня повідомлень

 

Безпечний Діалог GSI

Безпечне повідомлення GSI

Технологія

WS-SecureConversation

WS-Security

Конфіденційність (Кодируется)

так

так

Цілісність (Підписано)

так

так

Анонімнааутентифікація

так

ні

Делегація

так

ні

Робота

Хороша, якщо пересилається багато повідомлень

 

Хороша при невеликій пересилці повідомлень

 

 

 

 

5.3.2.2 Аутентифікація

Для вирішення аутентифікації і авторизації, необхідна наявність в системі центрів сертифікації (CA), а для крупних, територіально розподілених систем також і центру реєстрації (або інституту реєстраторів). Завдання CA – перевірити приналежність сертифікату даному індивідуумові. Кожен сертифікаційний центр проводить свою політику, яка визначає правила створення і підписання сертифікатів. GSI підтримує триаутентифікаційні методи:

Сертифікати X.509: Всі три схеми захисту, що вище перераховані, можуть використовуватися разом з сертифікатом X.509, щоб забезпечити покращувану аутентифікацію.

Ім'я користувача і пароль: Більш рудиментарна форма аутентифікації, імена користувача і паролі можуть також використовуватися. Проте, використовуючи імена користувача і пароль, не можна буде використовувати можливості конфіденційності, цілісності, і делегації.

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

Примітка: Оскільки не засвідчені зв'язки зазвичай не використовуються, література Globus, загалом, використовує термін методи аутентифікації, щоб послатися безпосередньо на Безпечний Діалог GSI,Безпечне Повідомлення GSI, і Транспорт GSI.

5.3.2.3 Авторизація

Хоча авторизація не є одним з “Фундаментальних стовпів” безпечного діалогу, вона, проте, складає важливу частину GSI. Авторизація відзначає, хто уповноважений виконувати певне завдання. У контексті веб-служб украй важливо знати, хто уповноважений використовувати визначену веб-службу.

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

Авторизація серверної сторони

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

None: Це найпростіший вид авторизації. В цьому випадку авторизація не виконуватиметься.

Self: Клієнтові дозволяється скористатися службою, якщо є тотожність клієнта і послуги.

Gridmap: “Gridmap” – список “зареєстрованих користувачів” який схожий з ACL (Список Контролю Доступу). При використанні цього виду авторизації, тільки перераховані в “gridmap” користувачі можуть її викликати.

Identity authorization: Клієнт може звернутися до обслуговування, якщо особа клієнта відповідає вказаній особі. Це подібно до наявності однокористувацьког “gridmap”, за винятком авторизації особи, яка конфігурується програмно, оскільки “gridmap” представлений як файл в системі.

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

SAML Callout authorization: Можна делегувати вирішення авторизації до OGSA (сумісна служба авторизації). OGSA-Authz (http://forge.gridforum.org/projects/ogsa-authz) – робоча група GGF, чия мета – конкретизувати стандартні компоненти авторизації. Одна з основних технологій, використовуваних в цих компонентах, – SAML (Мова Затвердження Підвищення Захисту).

Авторизація клієнтської сторони

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

None: Авторизація не виконуватиметься.

Self: Клієнт авторизує виклик, якщо особа служби співпадає з особою клієнта.

Identity authorization: Як викладено вище, клієнт тільки допустить відправку запитів до служб вказаній ідентичності.

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

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

Custom” авторизація

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

Делегація і єдиний вхід (проксі-сертифікати)

Для вирішення єдиного входу пропонується використовувати механізм генерації проксі-сертифікатів. Від процедури видачі сертифікату центром сертифікації, даний алгоритм відрізняється тим, що роль CA тут грає користувач (точніше його клієнтська програма), а сам сертифікат видається на вельми короткий проміжок часу (звичайно не більше 12-ти годин). Крім єдиного входу в систему механізм проксі-сертифікатів також дозволяє делегувати свої права, тобто дозволяє ресурсам системи (наприклад, веб-сервисам) виконувати різні завдання від імені клієнта і з його правами доступу. Розглянемо приклад показаний на Рисунку 5.11:

 

Рисунок 5.11 – Сценарій, де необхідна делегація

 

AliceOrg просить BobOrg виконати завдання. Оскільки BobOrg довіряє AliceOrg вона погоджується виконати завдання. Припустимо, що завдання Z дуже складне, і що одну з його підзадач (Y) повинна виконатитретя організація: CharlieOrg. В даному випадку, BobOrg запитає CharlieOrg виконати subtask Y, але запит не буде виконаний, оскільки CharlieOrg довіряє тільки AliceOrg. CharlieOrg може виконати дві дії:

-    Відкинути запит BobOrg. CharlieOrg не довіряє BobOrg, от і все.

-    Прийняти запит BobOrg. Справжня запрошуюча сторона AliceOrg, хоча CharlieOrg відповідає на запит від BobOrg, вона фактично здійснюватиме завдання для AliceOrg.

У цій ситуації логічно буде, якщо CharlieOrg прийме запит BobOrg. Проте CharlieOrg повинна знати, що запит BobOrg виконується від імені AliceOrg, як показано на Рисунку 5.12.

Рисунок 5.12 – Делегація

 

Звичайно, це не найбезпечніше рішення, оскільки хто-небудь міг запитати діяти на користь AliceOrg. Можливим рішенням може бути для CharlieOrg контактувати з AliceOrg кожного разу, коли вона отримує запит від імені AliceOrg. Проте в цьому випадку можуть виникнути деякі проблеми. Уявимо, що завдання Z складене з 20 різних підзадач, і що кожна підзадача відіслана до іншої організації BobOrg. AliceOrg буде переповнена повідомленнями, що повідомляють, що “BobOrg тільки що запитав виконати завдання від вашого імені... можете ви підтвердити, що це так?” У відповідь, AliceOrg довелося б засвідчити себе зі всіма тими організаціями і надати підтвердження.

Успішніше рішення могло так чи інакше змусити CharlieOrg вважати, що BobOrg – AliceOrg. Іншими словами, потрібно буде знайти законний шлях для BobOrg продемонструвати, що вона фактично, діє на користь AliceOrg. Одним із способів виконання цього може бути надання AliceOrg пари з відкритого і приватного ключів для BobOrg. Проте, це за межами даного питання. Важливо пам'ятати, що приватний ключ повинен зберігатися в таємниці, і відправляючи його іншій організації (не має значення наскільки їй довіряють) – це велике порушення в захисті. Для вирішення цієї проблеми буде потрібний спеціальний вид сертифікату, показаний на Рисунок 5.13.

 

Рисунок 5.13 – Проксі-сертифікат

 

Рішення: проксі-сертифікати

Сертифікат, показаний на Рисунку 5.14 називається проксі-сертифікатом. Словник Вебстера визначає проксі як “інструмент, яким уповноважена персона виконує справи іншого”. Як видно на зображенні, проксі-сертифікат дозволяє утримувачеві сертифікату діяти на користь іншого. Фактично, це подібно цифровим сертифікатам X.509, за винятком того, що вони не підписуються Центром Сертифікації (Certificate Authority); апідписується кінцевим користувачем. Дізнатися достовірність сертифікату можна, перевіривши його підпис (Організація А підписує сертифікат в цифровій формі).

Як бути із загальним ключем проксі-сертифіката, чий цей загальний ключ, організація A, організація B? Проксі-сертіфікат має пару відкритих ключів, що згенерували спеціально для проксі-сертификата. Ця пара відкритих ключів узгоджується взаємно з обома частинами (в даному випадку, А і B), і Організація А допустить діяти в її інтересах (в даному випадку B) тільки утримувача цієї пари приватних ключів.

На розглянутому зображенні є одна упущена деталь. Дозволяти кому-небудь діяти у ваших інтересах – ризикована справа. Можливо, їм довіряють зараз для виконання конкретного завдання, але хто-небудь з Організації B, можливо, скористається проксі-сертифікатом в майбутньому, щоб здійснити несанкціоновані дії від вашого імені. Тому, тривалість життя сертифікату зазвичай дуже обмежена (наприклад, до 12 годин). Це означає що, якщо проксі-сертифікат поставлений під загрозу, нападаючий не зможе довго їм користуватися. До того ж, проксі-сертифікати розширюють звичайні сертифікати X.509 додаючи їм додаткові надбудови безпеки, щоб більше обмежити їх функціональність (наприклад, визначаючи, що проксі-сертифікат може використовуватися тільки для певних завдань). Підводячи підсумки, розглянемо більш правильне представленняпроксі-сертифіката на Рисунку 5.14.

Рисунок 5.14 Проксі-сертіфікат з обмеженою тривалістю життя

Лекція 6. Тенденції розвитку сучасних інфраструктурних рішень

 

Коротка анотація лекції:

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

Мета лекції:

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

Текст лекції:

 

Розвиток апаратного забезпечення.

 

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

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

В 1941 році в німецькій Лабораторії Авіації у Берліні з’явилась модель Z3 Конрада Цузе яка стала одним з найбільш значних подій у розвитку комп'ютерів, тому що ця машина підтримувала обчислення як з плаваючою точкою, так і двійкову арифметику. Це пристрій розглядають як перший комп'ютер, який був повністю працездатним. Якщо мова програмування потрапляє в той же  обчислювальний клас, що машина Тьюринга її вважають «Turing - complete».

Перше покоління сучасних комп'ютерів з'явилося в 1943, коли були розроблені Марк I і машина Колос. З фінансовою підтримкою від IBM (International Business Machines Corporation) Марк був сконструйований і розроблений у Гарвардському університеті. Це був електромеханічний програмований комп'ютер загального призначення. Перше покоління комп'ютерів було побудовано з використанням з'єднаних проводів та електронних ламп (термоелектронних ламп). Дані зберігалися на паперових перфокартах. Колос використовувався під час Другої світової війни, щоб допомогти розшифрувати зашифровані повідомлення.

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

Інший комп'ютер загального призначення цієї ери був ENIAC (Електронний Числовий Інтегратор і Комп'ютер), який був побудований в 1946. Він був першим комп'ютером, здатним до перепрограмування, щоб вирішувати повний спектр обчислювальних проблем. ENIAC містив 18 000 термоелектронний ламп, що важив більше ніж 27 тонн, і споживав 25 кіловат на годину електроенергії. ENIAC виконував 100 000 обчислень в секунду. Винахід транзистора означало, що неефективні термоелектронні лампи могли бути замінені більш дрібними і надійними компонентами. Це було наступним головним кроком в історії обчислень.

Комп'ютери Transistorized відзначили появу другого покоління комп'ютерів, які домінували в кінці 1950 -их і на початку 1960 - их. Незважаючи на використання транзисторів і друкованих схем, ці комп'ютери були досить великими і дорогими. В основному вони використовувалися університетами та урядом. Інтегральна схема або чіп були розвинені Джеком Кілбі. Завдяки цьому досягненню він отримав Нобелівську премію з фізики в 2000 році.

Винахід Кілбі викликав вибух у розвитку комп'ютерів третього покоління. Навіть при тому, що перша інтегральна схема була проведена у вересні 1958, чіпи не використовувалися в комп'ютерах до 1963. Історію мейнфреймів - прийнято відраховувати з появи в 1964 році універсальної комп'ютерної системи IBM System/360, на розробку якої корпорація IBM затратила 5 млрд доларів.

Мейнфрейм - це головний комп'ютер обчислювального центру з великим об'ємом внутрішньої і зовнішньої пам'яті. Він призначений для завдань, що вимагають складні обчислювальні операції. Сам термін «мейнфрейм» походить від назви типових процесорних стійок цієї системи. У 1960 -х - початку 1980 - х років System/360 була беззаперечним лідером на ринку. Її клони випускалися в багатьох країнах, у тому числі - в СРСР (серія ЄС ЕОМ). У той час такі мейнфрейми, як IBM 360 збільшили здібності зберігання і обробки, інтегральні схеми дозволяли розробляти міні комп'ютери, що дозволило великій кількості маленьких компаній робити обчислення. Інтеграція високого рівня діодних схем призвела до розвитку дуже маленьких обчислювальних одиниць, що призвело до наступного кроку розвитку обчислень.

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

Комп'ютери четвертого покоління, які розвивалися в цей час, використовували мікропроцесор, який вміщає здатності комп'ютерної обробки на єдиному чіпі. Комбінуючи пам'ять довільного доступу (RAM), розроблену Intel, комп'ютери четвертого покоління були швидші, ніж будь -коли раніше і займали набагато меншу площу. Процесори Intel 4004 були здатні виконувати всього 60000 команд в секунду. Мікропроцесори, які розвинулися з Intel 4004 створені виготовлювачами для початку розвитку персональних комп'ютерів, маленьких і досить дешевих, щоб бути купленими широкою публікою. Першим комерційно доступним персональним комп'ютером став MITS Altair 8800, випущений в кінці 1974. У наслідку були випущені такі персональні комп'ютери, як Apple I і II, Commodore PET, VIC -20, Commodore 64, і, в кінцевому рахунку, оригінальний IBM -PC в 1981. Ера PC почалася всерйоз до середини 1980-их. Протягом цього час, IBM -PC, Commodore Amiga і Atari ST були найпоширенішими платформами PC, доступними громадськості. Навіть при тому, що мікрообчислювальна потужність, пам'ять і зберігання даних потужності збільшилися набагато порядків, починаючи з винаходу з Intel 4004 процесорів, технології чіпів інтеграції високого рівня (LSI) або інтеграція надвисокого рівня (VLSI) сильно не змінилися. Тому більшість сьогоднішніх комп'ютерів все ще потрапляє в категорію комп'ютерів четвертого покоління.

Одночасно з різким зростанням виробництва персональних комп'ютерів на початку 1990 - х почалася криза ринку мейнфреймів, пік якої припав на 1993 рік. Багато аналітиків заговорили про повне вимирання мейнфреймів, про перехід від централізованої обробки інформації до розподіленої (за допомогою персональних комп'ютерів, об'єднаних дворівневою архітектурою «клієнт - сервер»). Багато стали сприймати мейнфрейми як вчорашній день обчислювальної техніки, вважаючи Unix -і PC - сервери більш сучасними і перспективними.

З 1994 знову почалося зростання інтересу до мейнфреймів. Справа в тому, що, як показала практика, централізована обробка на основі мейнфреймів вирішує багато завдань побудови інформаційних систем масштабу підприємства простіше і дешевше, ніж розподілена. Багато з ідей, закладених у концепції хмарних обчислень також " повертають" нас до епохи мейнфреймів, зрозуміло з поправкою на час. Ще шість років тому в бесіді з Джоном Менлі, одним з провідних наукових співробітників центру досліджень і розробок HP в Брістолі, обговорювалася тема хмарних обчислень, і Джон звернув увагу на те, що основні ідеї cloud computing дуже нагадують мейнфрейми, тільки на іншому технічному рівні: «Все йде від мейнфреймів. Мейнфрейми навчили нас тому, як в одному середовищі можна ізолювати програми, - вміння, критично важливе сьогодні».

 

Сучасні інфраструктурні рішення.

 

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

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

• Поява систем і мереж зберігання даних

• Консолідація інфраструктури

 

Поява блейд - систем

 

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

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

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

Для вирішення цих проблем було створено новий тип серверів XXI століття - модульні, частіше звані Blade - серверами, або серверами - лезами (blade - лезо). Переваги Blade - серверів, перші моделі яких були розроблені в 2001 р. виробники описують за допомогою правила «1234». «Порівняно із звичайними серверами при порівнянній продуктивності Blade - сервери займають в два рази менше місця, споживають в три рази менше енергії і обходяться в чотири рази дешевше».

 

Рисунок 6.1 – Типовий Blade - сервер (Sun Blade X6250)

 

Що являє собою Blade - сервер? За визначенням, даним аналітичною компанією IDC Blade - сервер або лезо - це модульна одноплатна комп'ютерна система, що включає процесор і пам'ять. Леза вставляються в спеціальне шасі з об'єднавчою панеллю (backplane), що забезпечує їм підключення до мережі і подачу електроживлення. Це шасі з лезами, є Blade - системою. Воно виконане у конструктиві для установки в стандартну 19 дюймову стійку і залежно від моделі і виробника, займає в ній 3U, 6U або 10U (один U - unit, або монтажна одиниця, дорівнює 1,75 дюйма). За рахунок загального використання таких компонентів, як джерела живлення, мережеві карти і жорсткі диски, Blade - сервери забезпечують більш високу щільність розміщення обчислювальної потужності в стійці в порівнянні з звичайними тонкими серверами висотою 1U і 2U.

 

Рисунок 6.2 - Типове 10U шасі для 10 Blade - серверів (Sun Blade 6000) що використовується в УрГУ

 

Технологія блейд - систем запозичує деякі риси мейнфреймів. В даний час лідером у виробництві блейд - систем є компанії Hewlett - Packard, IBM, Dell, Fujitsu Siemens Computers, Sun.

 

Переваги Blade – серверів

 

Розглянемо основні переваги блейд - систем:

Унікальна фізична конструкція. Архітектура блейд - систем заснована на детально відпрацьованій унікальній фізичній конструкції. Спільне використання таких ресурсів, як кошти харчування, охолодження, комутації та управління, знижує складність і ліквідує проблеми, які характерні для більш традиційних стійкових серверних інфраструктур. Фізична конструкція блейд систем припускає розміщення блейд серверів в спеціальному шасі і основним її конструктивним елементом є об'єднавча панель. Об'єднавча панель розроблена таким чином, що вона вирішує всі завдання комутації блейд серверів із зовнішнім світом: з мережами Ethernet, мережами зберігання даних Fiber Channel а також забезпечує взаємодію по протоколу SAS (SCSI) з дисковими підсистемами в тому ж шасі. Шасі для Блейд також дозволяє розміщувати в ньому необхідні комутатори Ethernet або Fiber Channel для зв'язку з зовнішніми мережами. Вихід на ці комутатори з блейд серверів забезпечують передвстановлені або встановлювані додатково контролери. Засоби комутації в зовнішні мережі, інтегровані в загальну полку, значно скорочують кількість кабелів для підключення до ЛВС і SAN, ніж традиційні стоєчні сервери. Блейд сервери мають спільні кошти харчування та охолодження. Розміщення систем живлення і охолодження в загальній полиці, а не в окремих серверах, забезпечує зниження енергоспоживання та підвищення надійності.

Кращі можливості управління і гнучкість. Блейд - сервери принципово відрізняються від стійкових серверів тим, що серверна полку має інтелект у вигляді модулів управління, який відсутній в стійках при розміщенні традиційних серверів. Для управління системою не потрібно клавіатура, відео і мишка. Управління блейд системою здійснюється за допомогою централізованого модуля управління та спеціального процесора віддаленого управління на кожному блейд - сервері. Система управління шасі і серверами як правило мають досить зручне програмне забезпечення для управління. З'являються можливості дистанційно керувати всією «Blade» - системою, у тому числі управління електроживленням і мережею окремих вузлів.

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

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

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

 

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

 

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

Система Зберігання Даних (СЗД) - це програмно - апаратне рішення з організації надійного зберігання інформаційних ресурсів та надання до них гарантованого доступу.

Системи зберігання даних являють собою надійні пристрої зберігання, виділені в окремий вузол. Система зберігання даних може підключатися до серверів багатьма способами. Найбільш продуктивним є підключення по оптичних каналах (Fiber Channel), що дає можливість отримувати доступ до систем зберігання даних зі швидкостями 4 -8 Гбіт / сек. Системи зберігання даних так само мають резервування основних апаратних компонентів - кілька блоків живлення, raid контролерів, FC адаптерів і оптичних патчкордів для підключення до FC комутаторів.

 

Рисунок 6.3 - Типова Система зберігання даних початкового рівня (Sun StorageTek 6140)

 

Відзначимо основні переваги використання СЗД:

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

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

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

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

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

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

 

Мережі зберігання даних

 

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

Рушійною силою для розвитку мереж зберігання даних стало вибухове зростання обсягу бізнес інформації (такої як електронна пошта, бази даних і високонавантажені файлові сервера), що вимагає високошвидкісного доступу до дискових пристроїв на блочному рівні. Раніше на підприємстві виникали «острова» високопродуктивних дискових масивів SCSI. Кожен такий масив був виділений для конкретного додатку і представлявся як деяка кількість «віртуальних жорстких дисків». Мережа зберігання даних (Storage Area Network або SAN) дозволяє об'єднати ці «острова» засобами високошвидкісної мережі. Основу SAN становить волоконно - оптичне з'єднання пристроїв по інтерфейсу Fibre Chanel, що забезпечує швидкість передачі інформації між об'єктами 1,2,4 або 8 Mbit / sec. Мережі зберігання допомагають підвищити ефективність використання ресурсів систем зберігання, оскільки дають можливість виділити будь -який ресурс будь -якому вузлу мережі. Розглянемо основні переваги SAN:

• Продуктивність. Технології SAN дозволяють забезпечити високу продуктивність для задач зберігання і передачі даних.

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

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

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

• Відмовостійкість. Мережі зберігання допомагають більш ефективно відновлювати працездатність після збою. У SAN може входити віддалена ділянка з вторинним пристроєм зберігання. У такому випадку можна використовувати реплікацію - реалізовану на рівні контролерів масивів, або за допомогою спеціальних апаратних пристроїв. Попит на такі рішення значно зріс після подій 11 вересня 2001 року в США.

• Управління. Технології SAN дозволяють забезпечити централізоване управління всією підсистемою зберігання даних.

 

 

Топології SAN

 

Розглянемо деякі топології мереж зберігання даних

Однокомутаторна структура (англ. single - switch fabric) складається з одного комутатора Fibre Channel, сервера та системи зберігання даних. Зазвичай ця топологія є базовою для всіх стандартних рішень - інші топології створюються об'єднанням однокомутаторних осередків.

 

http://upload.wikimedia.org/wikipedia/ru/c/c1/Single-switch_fabric.jpg

Рисунок 6.4 - Однокомутаторна структура SAN

 

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

 

http://upload.wikimedia.org/wikipedia/ru/b/bb/Cascaded_Fabric.jpg

Рисунок 6.5 - Каскадна структура SAN

 

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

 

http://upload.wikimedia.org/wikipedia/ru/2/2f/Meched_Fabric.jpg

Рисунок 6.6 - Структура Решітка

 

Кільце - практично повторює схему топології решітка. Серед переваг - використання меншої кількості з'єднань.

 

http://upload.wikimedia.org/wikipedia/ru/3/3f/Ring_Fabric.jpg

Рисунок 6.7 - Структура Кільце

 

 

Консолідація ІТ інфраструктури

 

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

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

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

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

•  додатків - розміщення декількох додатків на одному хості.

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

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

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

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

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

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

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

 

Рисунок 6.8 - Консолідація додатків

 

Як відзначають фахівці з хмарним технологіям - консолідація ІТ - інфраструктури - є першим кроком до " хмари ". Щоб перейти до використання хмарних технологій, компаніям необхідно спочатку вирішити завдання неконсолідованим ІТ -інфраструктури. «Без консолідації неможливо побудувати ефективне процесно - орієнтоване управління, оскільки відсутня єдина точка надання сервісів».

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

Виступаючи на конференції, присвяченій проблемам сучасних процесорів, професор Массачусетського технологічного інституту Ананд Агарвал сказав: «Процесор - це транзистор сучасності». Новий рівень відрізняється тим, що тут також збираються мейнфрейми, але віртуальні, і не з окремих транзисторів, як півстоліття тому, а з цілих процесорів або цілком із комп'ютерів. На зорі ІТ численні компанії та організації «ліпили» власні комп'ютери з дискретних компонентів, монтуючи їх на саморобних друкованих платах - кожна організація робила свою машину, і ні про яку стандартизацію або уніфікацію і мови не могло бути. І ось на порозі другого десятиліття XXI століття ситуація повторюється - точно так само з серверів - лез, комп'ютерів, різноманітного мережного обладнання збираються зовнішні та приватні хмари. Одночасно спостерігається та ж сама технологічна роз'єднаність і відсутність уніфікації: Microsoft, Google, IBM, Aptana, Heroku, Rackspace, Ning, Salesforce будують глобальні мейнфрейми, а хтось під власні потреби створює приватні хмари, які є тими ж мейнфреймами, але меншого масштабу. Залишається припустити, що попереду є винахід інтегральної схеми і мікропроцесора.

Лекція 7. Технології віртуалізації

 

Коротка анотація лекції:

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

Мета лекції:

Мета даної лекції – отримати відомості про технології віртуалізації, термінології, різновиди і основнІ переваги віртуалізації. Ознайомитися з основними рішеннями провідних ІТ – вендорів. Розглянути особливості платформи віртуалізації Microsoft.

 

Текст лекції:

 

Технології віртуалізації

 

Згідно зі статистикою середній рівень завантаження процесорних потужностей у серверів під управлінням Windows не перевищує 10%, у Unix – систем цей показник кращий, проте в середньому не перевищує 20 %. Низька ефективність використання серверів пояснюється широко застосовуваним з початку 90 – х років підходом " один додаток – один сервер", тобто кожен раз для розгортання нової програми компанія набуває новий сервер. Очевидно, що на практиці це означає швидке збільшення серверного парку і як наслідок – зростання витрат на його адміністрування, енергоспоживання та охолодження, а також потреба в додаткових приміщеннях для установки все нових серверів і придбанні ліцензій на серверну ОС.

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

 

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

 

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

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

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

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

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

У 1999 р. компанія VMware представила технологію віртуалізації систем на базі x86 в якості ефективного засобу, здатного перетворити системи на базі x86 в єдину апаратну інфраструктуру загального користування та призначення, що забезпечує повну ізоляцію, мобільність і широкий вибір ОС для прикладних середовищ. Компанія VMware була однією з перших, хто зробив серйозну ставку виключно на віртуалізацію. Як показав час, це виявилося абсолютно виправданим. Сьогодні WMware пропонує комплексну віртуалізаційну платформу четвертого покоління VMware vSphere 4, яка включає засоби як для окремого ПК, так і для центру обробки даних. Ключовим компонентом цього програмного комплексу є гіпервізор VMware ESX Server. Пізніше в «битву» за місце у цьому модному напрямку розвитку інформаційних технологій включилися такі компанії як Parallels (раніше SWsoft), Oracle (Sun Microsystems), Citrix Systems (XenSourse).

Корпорація Microsoft вийшла на ринок засобів віртуалізації в 2003 р. з придбанням компанії Connectiх, випустивши свій перший продукт Virtual PC для настільних ПК. З тих пір вона послідовно нарощувала спектр пропозицій у цій галузі і на сьогодні майже завершила формування віртуалізаційних платформ, до складу якох входять такі рішення як Windows 2008 Server R2 c компонентом Hyper -V, Microsoft Application Virtualization (App – v), Microsoft Virtual Desktop Infrastructure (VDI), Remote Desktop Services, System Center Virtual Machine Manager.

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

Підвищений інтерес до технологій віртуалізації в даний час невипадковий. Обчислювальна потужність нинішніх процесорів швидко зростає, і питання навіть не в тому, на що цю потужність витрачати, а в тому, що сучасна «мода» на двоядерні і багатоядерні системи, що проникла вже і в персональні комп'ютери (ноутбуки та десктопи), як не можна краще дозволяє реалізувати багатющий потенціал ідей віртуалізації операційних систем та програм, виводячи зручність користування комп'ютером на новий якісний рівень. Технології віртуалізації стають одним з ключових компонентів (у тому числі, і маркетингових) в найновіших і майбутніх процесорах Intel і AMD, в операційних системах від Microsoft та ряду інших компаній.

Наведемо основні переваги технологій віртуалізації:

1. Ефективне використання обчислювальних ресурсів. Замість 3х, а то і 10 серверів, завантажених на 5 -20 % можна використовувати один, використовуваний на 50 -70 %. Крім іншого, це ще й економія електроенергії, а також значне скорочення фінансових вкладень: придбавається один високотехнологічний сервер, що виконує функції 5 -10 серверів. За допомогою віртуалізації можна досягти значно більш ефективного використання ресурсів, оскільки вона забезпечує об'єднання стандартних ресурсів інфраструктури в єдиний пул і долає обмеження застарілої моделі «одно додатків на сервер».

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

3. Зниження витрат на програмне забезпечення. Деякі виробники програмного забезпечення ввели окремі схеми ліцензування спеціально для віртуальних середовищ. Так, наприклад, купуючи одну ліцензію на Microsoft Windows Server 2008 Enterprise, ви отримуєте право одночасно її використовувати на 1 фізичному сервері і 4 віртуальних (в межах одного сервера), а Windows Server 2008 Datacenter ліцензується тільки на кількість процесорів і може використовуватися одночасно на необмеженій кількості віртуальних серверів.

4. Підвищення гнучкості і швидкості реагування системи: Віртуалізація пропонує новий метод управління ІТ – інфраструктурою і допомагає ІТ – адміністраторам затрачати менше часу на виконання повторюваних завдань – наприклад, на ініціацію, налаштування, відстеження і технічне обслуговування. Багатосистемні адміністратори відчували неприємності, коли «валиться» сервер. І не можна, витягнувши жорсткий диск, переставивши його в інший сервер, запустити все як раніше... А установка? пошук драйверів, настройка, запуск... і на все потрібні час і ресурси. При використанні віртуального сервера – можливий моментальний запуск на будь -якому “залізі“, а якщо немає подібного сервера, то можна скачати готову віртуальну машину з встановленим та настроєним сервером, з бібліотек, підтримуваних компаніями розробниками гіпервізорів (програм для віртуалізації).

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

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

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

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

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

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

ОС не може розрізнити віртуальну і фізичну машини. Те ж саме можна сказати про додатки та інших комп'ютерах в мережі. Навіть сама віртуальна машина вважає себе «справжнім» комп'ютером. Але незважаючи на це віртуальні машини складаються виключно з програмних компонентів і не включають обладнання. Це дає їм низку унікальних переваг над фізичною обладнанням.

 

Рисунок 7.2 – Віртуальна машина

 

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

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

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

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

4. Незалежність від обладнання. Віртуальні машини повністю незалежні від базового фізичного обладнання, на якому вони працюють. Наприклад, для віртуальної машини з віртуальними компонентами (ЦП, мережевою картою, контролером SCSI) можна задати налаштування, абсолютно не збігаються з фізичними характеристиками базового апаратного забезпечення. Віртуальні машини можуть навіть виконувати різні операційні системи (Windows, Linux та ін) на одному і тому ж фізичному сервері. У поєднанні з властивостями інкапсуляції і сумісності, апаратна незалежність забезпечує можливість вільно переміщувати віртуальні машини з одного комп'ютера на базі x86 на інший, не змінюючи драйвери пристроїв, ОС або програми. Незалежність від обладнання також дає можливість запускати в поєднанні абсолютно різні ОС і додатки на одному фізичному комп'ютері.

 

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

• віртуалізація серверів (повна віртуалізація і паравіртуалізації)

• віртуалізація на рівні операційних систем,

• віртуалізація додатків,

• віртуалізація уявлень.

 

Віртуалізація серверів

 

Сьогодні, говорячи про технології віртуалізації, як правило, мають на увазі віртуалізацію серверів, так як остання стає найбільш популярним рішенням на ринку IT. Віртуалізація серверів має на  увазі запуск на одному фізичному сервері декількох віртуальних серверів. Віртуальні машини або сервера являють собою програми, запущені на хостовій операційній системі, які емулюють фізичні пристрої сервера. На кожній віртуальній машині може бути встановлена ​​операційна система, на яку можуть бути встановлені додатки і служби. Типові представники це продукти VmWare (ESX, Server, Workstation) і Microsoft (Hyper -V, Virtual Serer, Virtual PC).

 

Рисунок 7.3 – Віртуалізація серверів

 

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

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

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

Не так давно з'явилися моделі останнього покоління процесорів в архітектурі x86 корпорацій AMD і Intel, де виробники вперше додали технології апаратної підтримки віртуалізації. До цього віртуалізація підтримувалася програмно, що природно приводила до великих накладних витрат продуктивності.

Для персональних  комп’ютерів вісімдесятих років двадцятого століття  – проблема віртуалізації апаратних ресурсів, здавалося б, не існувала за визначенням, оскільки кожен користувач отримував в своє розпорядження весь комп'ютер зі своєю ОС. Але у міру зростання  потужності ПК і розширення сфери застосування x86 – систем ситуація швидко змінилася. " Діалектична спіраль " розвитку зробила свій черговий виток, і на рубежі століть розпочався черговий цикл посилення доцентрових сил по концентрації обчислювальних ресурсів. На початку нинішнього десятиліття на тлі зростаючої зацікавленості підприємств у підвищенні ефективності своїх комп'ютерних засобів стартував новий етап розвитку технологій віртуалізації, який зараз переважно пов'язується саме з використанням архітектури x86.

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

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

Використання коштів x86 – віртуалізації почалося наприкінці 90 – х з робочих станцій: одночасно із збільшенням кількості версій клієнтських ОС постійно зростала і кількість людей (розробників ПЗ, фахівців з технічної підтримки, експертів), яким потрібно було на одному ПК мати відразу кілька копій різних ОС.

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

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

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

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

Багато труднощів і проблем розробки технологій віртуалізації пов'язані з подоланням успадкованих особливостей програмно – апаратної архітектури x86. Для цього існує кілька базових методів:

Повна віртуалізація (Full, Native Virtualization). Використовуються не модифіковані екземпляри гостьових операційних систем, а для підтримки роботи цих ОС служить загальний шар емуляції їх виконання поверх хостової ОС, в ролі якої виступає звичайна операційна система. Така технологія застосовується, зокрема, в VMware Workstation, VMware Server (колишній GSX Server, Parallels Desktop, Parallels Server, MS Virtual PC, MS Virtual Server, Virtual Iron. До переваг даного підходу можна зарахувати відносну простоту реалізації, універсальність і надійність рішення ; всі функції управління бере на себе хост -ОС. Недоліки – високі додаткові накладні витрати на використовувані апаратні ресурси, відсутність обліку особливостей гостьових ОС, менша, ніж потрібно, гнучкість у використанні апаратних засобів.

 

Рисунок 7.4 – Повна віртуалізація

 

Паравіртуалізації (paravirtualization). Модифікація ядра гостьової ОС виконується таким чином, що в неї включається новий набір API, через який вона може безпосередньо працювати з апаратурою,  не конфліктуючи з іншими віртуальними машинами. При цьому немає необхідності задіяти повноцінну ОС в якості хостового ПО, функції якого в даному випадку виконує спеціальна система, що отримала назву гіпервізора (hypervisor). Саме цей варіант є сьогодні найбільш актуальним напрямком розвитку серверних технологій віртуалізації і застосовується в VMware ESX Server, Xen (і рішеннях інших постачальників на базі цієї технології), Microsoft Hyper -V. Переваги даної технології полягають у відсутності потреби в хостової ОС – ВМ, встановлюються фактично на " голе залізо ", а апаратні ресурси

 

Рисунок 7.5 – Паравіртуалізації

 

Віртуалізація на рівні ядра ОС (operating system – level virtualization). Цей варіант передбачає використання одного ядра хостової ОС для створення незалежних паралельно працюючих операційних середовищ. Для гостьового ПО створюється тільки власне мережеве та апаратне оточення. Такий варіант використовується в Virtuozzo (для Linux і Windows), OpenVZ (безкоштовний варіант Virtuozzo) і Solaris Containers. Переваги – висока ефективність використання апаратних ресурсів, низькі накладні технічні витрати, відмінна керованість, мінімізація витрат на придбання ліцензій. Недоліки – реалізація тільки однорідних обчислювальних середовищ.

 

Рисунок 7.6 – Віртуалізація на рівні ОС

 

Віртуалізація додатків має на увазі застосування моделі сильної ізоляції прикладних програм з керованою взаємодією з ОС, при якій віртуалізується кожен екземпляр додатків, всі його основні компоненти: файли (включаючи системні), реєстр, шрифти, INI – файли, COM – об'єкти, служби. Додаток виповнюється без процедури інсталяції в традиційному її розумінні і може запускатися прямо з зовнішніх носіїв (наприклад, з флеш – карт або з мережевих папок). З точки зору ІТ – відділу, такий підхід має очевидні переваги: прискорення розгортання настільних систем і можливість управління ними, зведення до мінімуму не тільки конфліктів між додатками, а й потреби у тестуванні додатків на сумісність. Дана технологія дозволяє використовувати на одному комп'ютері, а точніше в одній і тій же операційній системі кілька несумісних між собою додатків одночасно. Віртуалізація додатків дозволяє користувачам запускати одне і теж заздалегідь сконфігуровантй додаток або групу додатків з сервера. При цьому додатки будуть працювати незалежно один від одного, не вносячи жодних змін в операційну систему. Фактично саме такий варіант віртуалізації використовується в Sun Java Virtual Machine, Microsoft Application Virtualization (раніше називався Softgrid), Thinstall (на початку 2008 р. увійшла до складу VMware), Symantec / Altiris.

 

Рисунок 7.7 – Віртуалізація додатків

 

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

 

Рисунок 7.8 – Віртуалізація уявлень

 

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

Разом з тим, із зростанням масштабів організацій, використання в ІТ – інфраструктурі користувацьких ПК викликає ряд складнощів:

• великі операційні витрати на підтримку комп'ютерного парку;

• складність, пов'язана з управлінням настільними ПК ;

• забезпечення користувачам безпечного і надійного доступу до ПЗ і додаткам необхідним для роботи ;

• технічний супровід користувачів;

• встановлення та оновлення ліцензій на ПЗ і технічне обслуговування;

• резервне копіювання і т.д.

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

VDI – комбінація сполук з віддаленим робочим столом і віртуалізацією. На обслуговуючих серверах працює безліч віртуальних машин, з такими клієнтськими операційними системами, як Windows 7, Windows Vista і Windows XP або Linux операційними системами. Користувачі дистанційно підключаються до віртуальної машини свого робочого середовища.

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

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

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

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

 

Рисунок 7.9 – Приклад тонкого клієнта. Термінал Sun Ray

 

Одним з найбільш відомих тонких клієнтів є термінал Sun Ray, для організації роботи якого використовується програмне забезпечення Sun Ray Server Software. Для початку сеансу Sun Ray достатньо лише вставити в цей пристрій ідентифікаційну смарт -карту. Застосування смарт – картки істотно підвищує мобільність користувача – він може переходити з одного Sun Ray на інший, переставляючи між ними свою картку і відразу продовжувати роботу зі своїми додатками з того місця, де він зупинився на попередньому терміналі. А відмова від жорсткого диска не тільки забезпечує мобільність користувачів і підвищує безпеку даних, але й істотно знижує енергоспоживання в порівнянні з звичайними ПК, тому термінал ВС не має вентилятора і працює практично безшумно. Крім того, скорочення числа компонентів тонкого терміналу зменшує і ризик виходу його з ладу, а отже, економить витрати на його обслуговування. Ще одна перевага Sun Ray – це істотно розширений в порівнянні із звичайними ПК життєвий цикл продукту, оскільки в ньому немає компонентів, які можуть морально застаріти.

 

Короткий огляд платформ віртуалізації

 

VMware

Компанія VMware – один з перших гравців на ринку платформ віртуалізації. У 1998 році VMware запатентувала свої програмні техніки віртуалізації і з тих пір випустила чимало ефективних і професійних продуктів для віртуалізації різного рівня: від VMware Workstation, призначеного для настільних ПК, до VMware ESX Server, що дозволяє консолідувати фізичні сервери підприємства у віртуальній інфраструктурі.

На відміну від ЕОМ (мейнфрейм) пристрої на базі x86 не підтримують віртуалізацію в повній мірі. Тому компанії VMware довелося подолати чимало проблем у процесі створення віртуальних машин для комп'ютерів на базі x86. Основні функції більшості ЦП (в ЕОМ і ПК) полягають у виконанні послідовності збережених інструкцій (тобто програм). У процесорах на базі x86 містяться 17 особливих інструкцій, що створюють проблеми при віртуалізації, через які операційна система відображає попереджувальне повідомлення, перериває роботу програми або просто видає загальний збій. Отже, ці 17 інструкцій виявилися значною перешкодою на початковому етапі впровадження віртуалізації для комп'ютерів на базі x86.

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

У вельми великому списку продуктів VMware можна знайти чимало інструментів для підвищення ефективності та оптимізації ІТ – інфраструктури, управління віртуальними серверами, а також кошти міграції з фізичних платформ на віртуальні. За результатами різних тестів продуктивності засоби віртуалізації VMware майже завжди за більшістю параметрів виграють у конкурентів. VMware має більше 100 000 клієнтів по всьому світу, в списку її клієнтів 100 % організацій зі списку Fortune 100. Мережа партнерств охоплює більше 350 виробників обладнання та ПЗ і більше 6000 реселерів. На даний момент обсяг ринку, що належить VMware, оцінюється на 80 %. Тим часом, серед платформ віртуалізації у VMware є з чого вибирати:

VMware Workstation – платформа, орієнтована на desktop -користувачів і призначена для використання розробниками ПЗ, а також професіоналами у сфері ІТ. Нова версія популярного продукту VMware Workstation 7 стала доступна в 2009 р, в якості хостових операційних систем підтримуються ОС Windows і Linux. VMware Workstation 7 може використовуватися спільно з середовищем розробки, що робить її особливо популярною в середовищі розробників, викладачів і фахівців технічної підтримки. Вихід VMware Workstation 7 означає офіційну підтримку Windows 7 як в якості гостьової, так і хостової операційної системи. Продукт включає підтримку Aero Peek і Flip 3D, що робить можливим спостерігати за роботою віртуальної машини, підбиваючи курсор до панелі завдань VMware або до відповідної вкладці на робочому столі хоста. Нова версія може працювати на будь -якій версії Windows 7, також як і будь -які версії Windows, можуть бути запущені у віртуальних машинах. Крім того, віртуальні машини в VMware Workstation 7, повністю підтримують Windows Display Driver Model (WDDM), що дозволяє використовувати інтерфейс Windows Aero у гостьових машинах.

VMware Player – безкоштовний «програвач» віртуальних машин на основі віртуальної машини VMware Workstation, призначений для запуску вже готових образів віртуальних машин, створених в інших продуктах VMware, а також у Microsoft VirtualPC і Symantec LiveState Recovery. Починаючи з версії 3.0 VMware Player дозволяє також створювати образи віртуальних машин. Обмеження функціональності тепер стосується в основному функцій, призначених для ІТ – спеціалістів та розробників ПЗ.

VMware Fusion – настільний продукт для віртуалізації на платформі Mac від компанії Apple.

VMware Server, Безкоштовний продукт VMware Server є досить потужною платформою віртуалізації, яка може бути запущена на серверах під управлінням хостових операційних систем Windows, і Linux. Основне призначення VMware Server – підтримка малих і середніх віртуальних інфраструктур невеликих підприємств. У зв'язку з невеликою складністю його освоєння і установки, VMware Server може бути розгорнутий в найкоротші терміни, як на серверах організацій, так і на комп'ютерах домашніх користувачів.

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

VMware VSPHERE – комплекс продуктів, що представляє надійну платформу для віртуалізації ЦОД. Компанія позиціонує даний комплекс також як потужну платформу віртуалізації для створення і розгортання приватної «хмари». VMware VSPHERE поставляється в декількох випусках з можливостями, призначеними спеціально для малих компаній і середніх компаній і корпорацій.

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

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

• Служби додатків – це компоненти, що мають вбудовані елементи управління рівнями обслуговування для всіх додатків на платформі платформи VSPHERE незалежно від їх типу або ОС.

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

 

Рисунок 7.10 – Структура платформи vShpere.

 

VMware ESX Server – це гіпервізор який розбиває фізичні сервери на безліч віртуальних машин. VMware ESX є основою пакету VMware VSPHERE і входить у всі випуски VMware VSPHERE.

 

Рисунок 7.11 – Гіпервизор VMware ESX

 

VMware VSPHERE Hypervisor (раніше VMware ESXi) – " полегшена " платформа віртуалізації корпоративного рівня, заснована на технологіях ESX. Продукт є безкоштовним і доступний для завантаження з сайту VMware. VSphere гіпервізора VMware є найпростішим способом для початку роботи з віртуалізацією

VMware Vcenter – надає розширювану і масштабовану платформу для попереджуючого управління віртуальною інфраструктурою і забезпечує отримання про неї всеосяжної інформації. VMware Vcenter сервер забезпечує централізоване управління середовищами VSPHERE і спрощує виконання повсякденних завдань, значно покращуючи адміністративне управління середовищем. Продукт має широкі можливості по консолідації серверів, їх налаштування та управління. VMware Vcenter сервер агрегує в собі всі аспекти управління віртуальним середовищем: від віртуальних машин до збору інформації про фізичних серверах для подальшої їх міграції у віртуальну інфраструктуру. Крім центрального продукту управління віртуальною інфраструктурою Vcenter сервера існує також ряд доповнень, що реалізують різні аспекти планування, управління та інтеграції розподіленої віртуальної інфраструктури (серверів VMware Vcenter серцебиття, VMware Vcenter Orchestrator, VMware Vcenter Ємність IQ, VMware Site Recovery Vcenter менеджер VMware Lab Manager Vcenter, VMware Vcenter Configuration Manager, VMware Vcenter перетворювач). Зокрема, Vcenter Конвертор призначений для перекладу у віртуальне середовище фізичних серверів, що дозволяє здійснювати «гарячу» (без зупину систем) та «холодну» міграцію. Vcenter Site Recovery Manager – це ПЗ для створення територіально – віддаленого резервного сегмента віртуальної інфраструктури, який у разі відмови основного вузла, бере на себе функції по запуску віртуальних машин у відповідності з планом відновлення після збоїв. Vcenter Lab Manager – продукт для створення інфраструктури зберігання і доставки конфігурацій віртуальних машин, що дозволяє організувати ефективну схему тестування в компаніях -розробниках ПЗ.

VMware ThinApp – колишній продукт Thinstall Virtualization Люкс, ПЗ для віртуалізації додатків, що дозволяє поширювати встановлені додатки на клієнтські робочі станції, скорочуючи час на стандартні операції з встановлення та конфігурації.

VMware View – комплекс продуктів, що забезпечує централізацію користувача робочих станцій у віртуальних машинах на платформі VSPHERE. Це дозволяє скоротити витрати на стандартні ІТ – операції, пов'язані з розгортанням та обслуговуванням користувальницьких десктопів.

VMware Capacity Planner – засіб централізованого збору та аналізу даних про апаратне і програмне забезпечення серверів, а також продуктивності обладнання. Ці дані використовуються авторизованими партнерами VMware для побудови планів консолідації віртуальних машин на платформі VMware ESX Server.

VMware VMmark – продукт, доступний тільки виробникам апаратного забезпечення, призначений для тестування продуктивності VMware ESX Server на серверних платформах.

 

Citrix (Xen)

 

Розробка некомерційного гіпервізора Xen починалася як дослідницький проект комп'ютерної лабораторії Кембриджського університету. Засновником проекту та його лідером був Іан Пратт (Ian Pratt) співробітник університету, який створив згодом компанію XenSource, що займається розробкою комерційних платформ віртуалізації на основі гіпервізора Xen, а також підтримкою Open Source співтовариства некомерційного продукту Xen. Спочатку Xen представляв собою найрозвиненішу платформу, що підтримує технологію паравіртуалізації. Ця технологія дозволяє гіпервізорами в хостової системі керувати гостьовий ОС допомогою гіпервизовов ДМС (Virtual – машинний інтерфейс), що вимагає модифікації ядра гостьової системи. На даний момент безкоштовна версія Xen включена в дистрибутиви декількох ОС, таких як Red Hat, Novell SUSE, Debian, Fedora Core, Sun Solaris. У середині серпня 2007 року компанія XenSource була поглинена компанією Citrix Systems. Сума проведеної операції близько 500 мільйонів доларів (акціями та грошовими коштами) говорить про серйозні наміри Citrix щодо віртуалізації. Експерти вважають, що не виключена і покупка Citrix компанією Microsoft, враховуючи її давню співпрацю з XenSource.

Безкоштовний Xen. В даний час Open Source версія платформи Xen застосовується в основному в освітніх і дослідницьких цілях. Деякі вдалі ідеї, реалізовані численними розробниками з усього світу, знаходять своє відображення в комерційних версіях продуктів віртуалізації компанії Citrix. Зараз безкоштовні версії Xen включаються до дистрибутиви багатьох Linux – систем, що дозволяє їх користувачам застосовувати віртуальні машини для ізоляції програмного забезпечення в гостьових ОС з метою його тестування і вивчення проблем безпеки, без необхідності установки платформи віртуалізації. До того ж багато незалежні розробники ПЗ можуть поширювати його за допомогою віртуальних шаблонів, в яких вже встановлена ​​і налаштована гостьова система і пропонований продукт. Крім того, Xen ідеально підходить для підтримки старого програмного забезпечення у віртуальній машині. Для більш  серйозних цілей у виробничому середовищі підприємства необхідно використовувати комерційні платформи компанії Citrix.

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

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

Citrix XenDesktop – рішення з віртуалізації десктопів підприємства, що дозволяє централізовано зберігати і доставляти робочі оточення у віртуальних машинах користувачам. Продукт підтримує кілька сценаріїв доставки додатків на настільні ПК, тонкі клієнти і мобільні ПК і сумісний з серверними віртуалізаційними рішеннями конкурентів.

 

Microsoft

 

Для Microsoft все почалося, коли в 2003 році вона придбала компанію Connectix, одну з небагатьох компаній виробляє програмне забезпечення для віртуалізації під Windows. Разом з Connectix, компанії Microsoft дістався продукт Virtual PC,що конкурував тоді з розробками компанії VMware щодо настільних систем віртуалізації. За великим рахунком, Virtual PC надавав тоді таку кількість функцій, що і VMware Workstation, і при належній увазі міг би бути в даний час повноцінним конкурентом цієї платформи. Проте з того часу, компанія Microsoft випускала по мінорному релізу на рік, не приділяючи особливої ​​уваги продукту Virtual PC, в той час як VMware стрімко розвивала свою систему віртуалізації, перетворивши її по – справжньому в професійний інструмент. Усвідомивши своє технологічне відставання у сфері віртуалізації серверних платформ, компанія Microsoft випустила продукт Virtual Server 2005, націлений на створення і консолідацію віртуальних серверів організацій. Однак було вже пізно. Компанія VMware вже захопила лідерство в цьому сегменті ринку, пропонуючи в той момент дві серверні платформи віртуалізації VMware GSX сервера і VMware ESX Server, кожна з яких за багатьма параметрами перевершувала платформу Microsoft. Остаточний удар був нанесений в 2006 році, коли VMware фактично оголосила продукт VMware GSX сервера безкоштовним, взявшись за розробку продукту VMware Server на його основі і сконцентрувавши всі зусилля на продажах потужної корпоративної платформи VMware ESX Server у складі віртуальної інфраструктури Virtual Infrastructure 3.

У компанії Microsoft був тільки єдиний вихід у цій ситуації: у квітні 2006 року вона також оголосила про безкоштовність продукту Microsoft Virtual Server 2005. Також існуючі раніше два видання Standard Edition і Enterprise Edition були об'єднані в одне – Microsoft Virtual Server Enterprise Edition. З тих пір Microsoft істотно змінила стратегію щодо віртуалізації, і влітку 2008 року був випущений фінальний реліз платформи віртуалізації Microsoft Hyper -V, інтегрованої в ОС Windows Server 2008. Тепер роль сервера віртуалізації доступна всім користувачам нової серверної операційної системи Microsoft.

Microsoft Virtual Server. Серверна платформа віртуалізації Microsoft Virtual Server може використовуватися на сервері під управлінням операційної системи Windows Server 2003 і призначена для одночасного запуску декількох віртуальних машин на одному фізичному хості. Платформа безкоштовна і надає тільки базові функції.

Microsoft Virtual PC. Продукт Virtual PC був куплений корпорацією Microsoft разом з компанією Connectix і вперше під маркою Microsoft був випущений як Microsoft Virtual PC 2004. Купуючи Virtual PC і компанію Connectix, компанія Microsoft будувала далекосяжні плани щодо забезпечення користувачів інструментом для полегшення міграції на наступну версію операційної системи Windows. Тепер Virtual PC 2007 безкоштовний і доступний для підтримки настільних ОС у віртуальних машинах.

Microsoft Hyper -V. Продукт Microsoft позиціонується як основний конкурент VMware ESX Server в області корпоративних платформ віртуалізації. Microsoft Hyper -V являє собою рішення для віртуалізації серверів на базі процесорів з архітектурою x64 в корпоративних середовищах. На відміну від продуктів Microsoft Virtual Server або Virtual PC, Hyper -V забезпечує віртуалізацію на апаратному рівні, з використанням технологій віртуалізації, вбудованих в процесори. Hyper -V забезпечує високу продуктивність, практично рівну продуктивності однієї операційної системи, що працює на виділеному сервері. Hyper -V поширюється двома способами: як частина Windows Server 2008 або у складі незалежного безкоштовного продукту Microsoft Hyper – V Server.

У Windows Server 2008 технологія Hyper -V може бути розгорнута як у повній установці, так і в режимі Server Core, Hyper – V Server працює тільки в режимі Core. Це дозволяє повною мірою реалізувати всі переваги «тонкої», економічною і керованої платформи віртуалізації.

Hyper -V є вбудованим компонентом 64 – розрядних версій Windows Server 2008 Standard, Windows Server 2008 Enterprise і Windows Server 2008 Datacenter. Ця технологія недоступна в 32 – розрядних версіях Windows Server 2008, в Windows Server 2008 Standard без Hyper -V, Windows Server 2008 Enterprise без Hyper -V, Windows Server 2008 Datacenter без Hyper -V, в Windows Web Server 2008 і Windows Server 2008 для систем на базі Itanium.

Розглянемо коротко особливості архітектури Hyper – v. Hyper – v являє собою гіпервізор, тобто прошарок між обладнанням та віртуальними машинами рівнем нижче операційної системи. Ця архітектура була спочатку розроблена IBM в 1960 -і роки для мейнфреймів і нещодавно стала доступною на платформах x86/x64, як частина низки рішень, включаючи Windows Server 2008 Hyper – V і Vmware ESX.

 

Рисунок 7.12 – Архітектура віртуалізації з гіпервізором

 

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

 

Рисунок 7.13 – Архітектура монолітного гіпервізора

 

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

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

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

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

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

• Труднощі з використанням непідтримуваного обладнання. Наприклад, ви зібралися використовувати обладнання «Сервер» досить потужний і надійний, але при цьому в гіпервізора не виявилося потрібного драйвера для RAID – контролера або мережного адаптера. Це зробить неможливим використання відповідного обладнання, а, значить, і сервера.

Мікроядерний підхід використовує дуже тонкий, спеціалізований гіпервізор, що виконує лише основні задачі забезпечення ізоляції розділів і управління пам'яттю. Цей рівень не включає стеку введення / виводу або драйверів пристроїв. Це підхід, який використовується  у Hyper -V. У цій архітектурі стек віртуалізації і драйверів конкретних пристроїв розташовані в спеціальному розділі ОС, іменованому батьківським розділом.

 

Рисунок 7.14 – Архітектура мікроядерного гіпервізора

 

У мікроядерній реалізації можна говорити про «тонкий гіпервізор», в цьому випадку в ньому зовсім немає драйверів. Замість цього драйвери працюють в кожному індивідуальному розділі, щоб будь -яка гостьова ОС мала можливість отримати через гіпервізор доступ до обладнання. При такій розстановці сил кожна віртуальна машина займає цілком відокремлений розділ, що позитивно позначається на захищеності і надійності. У мікроядерної моделі гіпервізора (у віртуалізації Windows Server 2008 R2 використовується саме вона) один розділ є батьківським (parent), решта – дочірніми (child). Розділ – це найменша ізольована одиниця, підтримувана гіпервізором. Розмір гіпервізора Hyper -V менше 1,5 Мб, він може поміститися на одну 3.5 – дюймову дискету.

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

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

Перевага мікроядерного підходу, застосованого в Windows Server 2008 R2, порівняно з монолітним підходом полягає в тому, що драйвери, які повинні розташовуватися між батьківським розділом і фізичним сервером, не потребують внесення жодних змін в модель драйверів. Іншими словами, у системі можна просто застосовувати існуючі драйвери. У Microsoft обрали  цей підхід, оскільки необхідність розробки нових драйверів сильно загальмувала б розвиток системи. Що ж стосується гостьових ОС, вони будуть працювати з емуляторами або синтетичними пристроями.

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

 

Рисунок 7.15 – Архітектура Hyper – v

 

Всі версії Hyper – V мають один батьківський розділ. Цей розділ керує функціями Hyper -V. З батьківського розділу запускається консоль Windows Server Virtualization. Крім того, батьківський розділ використовується для запуску віртуальних машин (VM), що підтримують потокову емуляцію старих апаратних засобів. Такі VM, побудовані на готових шаблонах, емулює апаратні засоби, є аналогами VM, що працюють в продуктах з віртуалізацією на базі хосту, наприклад Virtual Server.

Гостьові VM запускаються з дочірніх розділів Hyper -V. Дочірні розділи підтримують два типи VM: високопродуктивні VM на основі архітектури VMBus і VM, керовані системою – хостом. У першу групу входять VM з системами Windows Server 2003, Windows Vista, Server 2008 і Linux (підтримуючими Xen). Нову архітектуру VMBus відрізняє високопродуктивний конвеєр, функціонуючий в оперативній пам'яті, що з'єднує клієнтів Virtualization Service Clients (VSC) на гостьових VM з провайдером Virtual Service Provider (VSP) хоста. VM, керовані хостом, запускають платформи, які не підтримують нову архітектуру VMBus: Windows NT, Windows 2000 і Linux (без підтримки технології Xen, наприклад SUSE Linux Server Enterprise 10).

Microsoft System Center Virtual Machine Manager (SCVMM) – окремий продукт сімейства System Center для управління віртуальною інфраструктурою, ефективного використанням ресурсів фізичних вузлів, а також спрощення підготовки та створення нових гостьових систем для адміністраторів і користувачів. Продукт забезпечує всебічну підтримку консолідації фізичних серверів у віртуальній інфраструктурі, швидке та надійне перетворення фізичних машин у віртуальні, розумне розміщення віртуальних навантажень на відповідних фізичних вузлах, а також єдину консоль для управління ресурсами та їх оптимізації. SCVMM забезпечує наступні можливості:

• Централізоване управління серверами віртуальних машин в масштабах підприємства. SCVMM підтримує управління серверами Microsoft Hyper -V, Microsoft Virtual Server, VMware ESX і в майбутньому буде реалізована підтримка Xen.

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

• Моніторинг та розміщення віртуальних машин у відповідність із завантаженістю фізичних серверів.

• Міграція (конвертація) фізичних серверів у віртуальні машини – технологія P2V. Технологія P2V дозволяє зробити перенесення фізичного сервера на віртуальний без зупинки роботи. Таким чином, з'являється можливість онлайнового резервування цілого сервера, і в разі виходу його з ладу, можна протягом хвилини запустити віртуальний сервер і продовжити роботу.

• Міграція (конвертація) віртуальних машин інших форматів у віртуальні машини Hyper -V – технологія V2V. Дана технологія аналогічна P2V, але при цьому дозволяє переносити віртуальні машини Microsoft Virtual Server або VMware ESX в Hyper -V.

• Управління кластерами Hyper -V.

 

 

 

Короткі підсумки:

 

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

 

Ключові терміни:

 

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

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

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

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

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

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

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

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

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

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

Лекція 8. Основи хмарних обчислень

 

Коротка анотація лекції:

 

Мета лекції:

 

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

 

Текст лекції:

 

У попередніх лекціях ми розглянули дві ключових тенденції, що визначили появу концепції хмарних обчислень. Це консолідація і віртуалізація ІТ -інфраструктури. Третім ключовим компонентом або третім китом Cloud Computing є поняття Software as a Service (SaaS).

 

Рисунок 8.1 – Приклади застосування концепції SaaS

 

Перші ідеї про використання обчислень як публічної послуги були запропоновані ще в 1960 – х відомим вченим в галузі інформаційних технологій, винахідником мови Lisp, професором MIT і Стенфордського університету Джоном Маккарті (John McCarthy). Реалізація першого реального проекту приписується компанії Salesforce.com, заснованої в 1999 році. Саме тоді і з'явилося перше речення нового виду b2b продукту «Програмне забезпечення як сервіс» (" Software as a Service ", " SaaS "). Певний успіх Salesforce в цій області порушив інтерес у гігантів ІТ індустрії, які поспіхом повідомили про свої дослідження в області хмарних технологій. І ось вже перше бізнес – рішення під назвою «Amazon Web Services» було запущено в 2005 році компанією Amazon.com, яка з часів кризи доткомів активно займалася модернізацією своїх датацентрів. Наступним свою технологію поступово ввела Google, почавши з 2006 року b2b пропозицію SaaS сервісів під назвою «Google Apps». І, нарешті, свою пропозицію анонсувала компанія Microsoft, презентувавши її на конференції PDC 2008 під назвою «Azure Services Platform».

 

Рисунок – 8.2 SaaS сервіси Google

 

Сам факт високої зацікавленості найбільших гравців ринку ІТ демонструє певний статус хмарних обчислень як тренда 2009 -2010 років. Крім того, з релізом Microsoft Azure Service Platform безліч експертів пов'язує новий виток розвитку веб – технологій і вихід всієї сфери хмарних обчислень на новий рівень.

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

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

Види хмарних обчислень

З поняттям хмарних обчислень часто пов'язують сервіси що мають (Everything as a service) технології, такі як:

• «Інфраструктура як сервіс» (" Infrastructure as a Service " або " IaaS ")

• «Платформа як сервіс» (" Plaatform as a Service ", " PaaS ")

• «Програмне забезпечення як сервіс» (" Software as a Service " або " SaaS ").

 

Розглянемо кожну з цих технологій докладніше.

Інфраструктура як сервіс (IaaS)

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

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

• Апаратні засоби (сервери, системи зберігання даних, клієнтські системи, мережеве обладнання)

• Операційні системи та системне ПЗ (засоби віртуалізації, автоматизації, основні засоби управління ресурсами)

•    Сполучне ПО (наприклад, для управління системами).

 

Рисунок 8.2 – Компоненти хмарної інфраструктури

 

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

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

Першопрохідцями в IaaS вважається компанія Amazon, які на сьогоднішній день пропонують два основних IaaS – продукту: EC2 (Elastic Compute Cloud) і S3 (Simple Storage Service). EC2 являє собою Xen -хостинг зі статичними VPS – характеристиками, що не розширюються на льоту (хоча багато подібні сервіси вже надають т.зв. auto scaling). Сховище S3 має інтерфейс WebDAV і підтримує роботу з багатьма відомими мовами програмування.

Серед інших інфра – сервісних компаній можна відзначити:

GoGrid має дуже зручний інтерфейс для управління VPS, а також cloud storage з підтримкою протоколів SCP, FTP, SAMBA / CIFS, RSYNC, причому розмір сховища масштабується на льоту. Незабаром розробники обіцяють додати управління за допомогою API.

Enomaly являє собою рішення для розгортання та управління віртуальними додатками в хмарі, при цьому управління послугами здійснюється через браузер. Приємним доповненням є автоматичне масштабування віртуальних машин під поточного навантаження, а також автобалансування навантаження. Серед підтримуваних віртуальних архітектур підтримуються Linux, Windows, Solaris і BSD Guests. Для віртуалізації застосовують не тільки Xen, але і KVM, а також VMware.

Eucalyptus являє собою програмний комплекс з відкритим кодом для реалізації cloud computing на кластерних системах. В даний час інтерфейс сумісний з Amazon EC2, але заявлена ​​підтримка та інших.

 

Платформа як сервіс (PaaS)

 

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

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

Такий підхід має такі переваги:

• масштабованість ;

• відмовостійкість ;

• віртуалізація ;

• безпеку.

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

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

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

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

У системах веб-пошуку і контекстної реклами компанії Yahoo використовується платформа Hadoop, орієнтована на передачу великих обсягів даних між мережевими серверами. На базі Hadoop побудовані HBase (аналог бази даних Google BigTable), а також HDFS (Hadoop Distributed File System, аналог Google File System).

Ще одним яскравим представником PaaS є продукти компанії Mosso:

-Cloud Sites – веб-хостинг (Linux, Windows, Mail) для навантажувальних веб – проектів з можливістю розширювати базові безкоштовні – можливості за додаткову плату (трафік, сховище даних, обчислювальна потужність).

-Cloud Files – файловий cloud-хостинг з щомісячною погігабайтной оплатою за обсяг збережених файлів. Управління здійснюється через браузер, або за допомогою API (PHP, Python, Java, .NET, Ruby).

-Cloud Servers – погодинна оренда серверів (RAM на годину), з можливістю вибору серверної ОС. Можна змінювати характеристики сервера, але не в режимі реального часу. Незабаром розробники обіцяють зробити API для управління серверами.

Ну а в центрі всієї хмарної інфраструктури Microsoft – операційна система Windows Azure. Windows Azure створює єдине середовище, що включає хмарні аналоги серверних продуктів Microsoft (реляційна база даних SQL Azure, що є аналогом SQL Server, а також Exchange Online, SharePoint Online і Microsoft Dynamics CRM Online) і інструменти розробки ( .NET Framework і Visual Studio, оснащена в версії 2010 наборомWindows Azure Tools). Так, наприклад, програміст, що створює сайт в Visual Studio 2010, може не виходячи з програми розмістити свій сайт в Windows Azure.

 

Програмне забезпечення як сервіс (SaaS).

 

 

SaaS – модель розгортання програми, яка надає додаток кінцевому користувачеві як послугу на вимогу (on demand). Доступ до такого додатку здійснюється за допомогою мережі, а найчастіше за допомогою Інтернет-браузера.

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

У моделі SaaS:

•додаток пристосований для віддаленого використання;

•одним додатком можуть користуватися декілька клієнтів;

•оплата за послугу стягується або як щомісячна абонентська плата, або на основі сумарного обсягу транзакцій;

•підтримка програми входить вже до складу оплати;

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

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

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

Розвитком логіки SaaS є концепція WaaS (Workplace as a Service – робоче місце як послуга). Тобто клієнт отримує в своє розпорядження повністю оснащене всім необхідним для роботи ПЗ віртуальне робоче місце.

За нещодавно опублікованими даними SoftCloud попитом користуються наступні SaaS додатки (у порядку убування популярності):

•Пошта

•Комунікації (VoIP)

•Антиспам і антивірус

•Helpdesk

•Управління проектами

•Дистанційне навчання

•CRM

•Зберігання і резервування даних

Рисунок 8.3 – Сервіси SaaS мають найбільшу споживчу базу

 

Дуже схожими є продукти MobileMe (Apple), Azure (Microsoft) і LotusLive (IBM). Суть даних сервісів в тому, що вони надають користувачам доступ до зберігання своїх даних (контакти, пошта, файли), а також для спільної роботи декількох користувачів з документами.

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

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

Ще одним цікавим представником виду SaaS є продукт iCloud, який представляє собою операційну систему, працювати з якою можна безпосередньо через браузер. Інтерфейс операційної системи виконаний в стилі Windows Vista/ XP. На сьогоднішній день проект знаходиться у стадії бети і в самій ОС реалізований мінімум додатків.

Також до SaaS належать послуги Online backup, або, простіше кажучи – резервного копіювання даних. Користувач просто платить абонентську плату, а сервіси самі автоматично в певний час шифрують дані з комп'ютера або іншого пристрою і відправляють їх на віддалений сервер, тим самим дані можуть бути доступні з будь-якої точки земної кулі. Дану послугу зараз надають безліч компаній, у тому числі, такі як Nero і Symantec.

Цікаве застосування cloud-технологій знайшли і розробники комп'ютерних ігор: тепер сучасним комп'ютерам і ігровим приставкам не будуть потрібні потужні графічні адаптери (відеокарти), адже вся обробка даних і рендеринг будуть проводитися cloud-серверами, а гравці будуть отримувати вже оброблене відео. Одним із перших заявив про себе сервіс OnLive, і зовсім недавно про це заговорила і компанія Sony, яка збирається впровадити дану ідею в Playstation 3.

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

Конкуренція в хмарній сфері призвела до появи безкоштовних сервісів. Саме по такому шляху пішли два конкуренти – Microsoft і Google. Обидві компанії випустили набори сервісів, що дозволяють працювати з документами. У Google – це Google Docs, у Microsoft – Office Web Apps.

При цьому, обидва сервісу тісно взаємопов'язані з поштою (Gmail в першому випадку і Hotmail у другому) і файловими сховищами. Таким чином, користувача як би переводять зі звичної йому оффлайн-середовища в онлайн. Важливо, що і Google, і Microsoft інтегрують підтримку своїх онлайн-сервісів в усі програмні середовища – як настільні, так і мобільні (нагадаємо, що Google створила ОС Android, а Microsoft – Windows Phone 7).

Аналогічну концепцію (але з дещо іншими акцентами) просуває і головний конкурент обох компаній – Apple. Йдеться про дуже цікавому сервісі під назвою MobileMe. Сервіс включає в себе поштовий клієнт, календар, адресну книгу, файлове сховище, альбом фотографій та інструмент для виявлення загубленого iPhone. За можливість користуватися всім цим Apple бере приблизно 65 євро (або 100 доларів) на рік. При цьому Apple забезпечує такий рівень взаємодії свого набору інтернет-сервісів і додатків на комп'ютері (під управлінням Mac OS X), телефоні, плеєрі і iPad, що необхідність у використанні браузера пропадає. Ви користуєтеся звичними програмами на своєму Mac, iPhone і iPad, однак, всі дані зберігаються не на них, а в хмарі, що дозволяє забути про необхідність синхронізації, а також – про їх доступність.

Якщо Apple інтегрує веб-сервіси у звичні додатки операційної системи, то Google заходить з протилежного боку: операційна система Chrome OS являє собою, фактично, один браузер, через який користувач взаємодіє з розгалуженою мережею веб-сервісів. ОС орієнтована на нетбуки, відзначаються дуже низькі системні вимоги і відсутність необхідності самостійної установки програм (так як всі програми працюють безпосередньо в інтернеті). Тобто Google надає переваги хмарної концепції, зазвичай декламовані при роботі з корпоративними клієнтами, звичайним користувачам. Разом з тим, очевидна неможливість використання таких нетбуків в країнах з недостатньо широким проникненням широкосмугового інтернету. Тому що без інтернету нетбук на базі Chrome OS буде абсолютно даремний.

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

 

Рисунок 8.4 – Взаємозв'язок хмарних сервісів

 

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

Приватна хмара (private cloud) – використовується для надання сервісів всередині однієї компанії, яка є одночасно і замовником і постачальником послуг. Це варіант реалізації «хмарної концепції», коли компанія створює її для себе самої, в рамках організації. У першу чергу реалізація private cloud знімає одне з важливих питань, яке неодмінно виникає у замовників при ознайомленні з цією концепцією – питання про захист даних з точки зору інформаційної безпеки. Оскільки «хмара»обмежена рамками самої компанії, це питання вирішується стандартними існуючими методами. Для private cloud характерне зниження вартості обладнання за рахунок використання простоюють або неефективно використовуваних ресурсів. А також, зниження витрат на закупівлі обладнання за рахунок скорочення логістики (не думаємо, які сервера закуповувати, в яких конфігураціях, які продуктивні потужності, скільки місця кожного разу резервувати і т.д.

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

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

Змішана (гібридна) хмара – спільне використання двох перерахованих вище моделей розгортання

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

 

Рисунок 8.5 – Взаємозв'язок хмар різних типів

 

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

 

Переваги хмарних обчислень

 

Розглянемо основні переваги та гідності технологій хмарних обчислень:

Доступність і відмовостійкість-всім користувачам, з будь-якої точки де є Інтернет, з будь-якого комп'ютера, де є браузер.

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

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

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

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

Економічність та ефективність – плати стільки, скільки використовуєш, дозволь собі дорогі, потужні комп'ютери і програми. «Хмара»дозволяє враховувати і оплачувати тільки фактично спожиті ресурси строго за фактом їх використання;

Оренда ресурсів. Звичайні сервера середньої компанії завантажені на 10-15 %. В одні періоди часу є потреба в додаткових обчислювальних ресурсах, в інших ці ​​дорогі ресурси простоюють. Використовуючи необхідну кількість обчислювальних ресурсів в «хмарі»в будь-який момент часу, компанії скорочують витрати на обладнання та його обслуговування. Це дає можливість замовнику відмовитися від закупівель дорогих ІТ-активів на користь їх навіть не оренди, а операційного споживання в міру потреби, при скороченні витрат на обслуговування своїх систем та отриманні від постачальника гарантій рівня сервісу.

Оренда ПЗ. Замість придбання пакетів програм для кожного локального користувача, компанії купують потрібні програми в «хмарі». Дані програми будуть використовуватися тільки користувачами, для яких ці ​​програми необхідні в роботі. Більше того, вартість програм, орієнтованих на доступ через Інтернет, значно нижче, ніж їх аналогів для персональних комп'ютерів. Якщо програми використовуються не часто, то їх можна просто орендувати з погодинною оплатою. Витрати на оновлення програм і підтримку в працездатному стані на всіх робочих мріях зовсім зведені до нуля.

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

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

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

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

Відкриті інтерфейси. «Хмара» як правило, має стандартні відкриті API (інтерфейси прикладного програмування) для зв'язку з існуючими додатками і розробки нових – спеціально для хмарної архітектури.

Гнучкість і масштабованість – необмеженість обчислювальних ресурсів (пам'ять, процесор, диски). «Хмара» масштабованість і еластично – ресурси виділяються і звільняються у міру потреби;

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

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

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

Недоліки та проблеми хмарних обчислень

Чи є мінуси в «хмарних» обчислень ? Чому «хмарні» технології в Росії тільки набирають обертів, а директори деяких великих компаній не поспішають переводити ІТ-інфраструктуру своїх підприємств в «хмари»? Отже, відзначимо основні недоліки і труднощі використання cloud computing:

Постійне з'єднання з мережею. Cloud Computing завжди майже завжди вимагає з'єднання з мережею (Інтернет). Якщо немає доступу в мережу – немає роботи, програм, документів. Багато «хмарні» програми вимагають хорошого Інтернет-з'єднання з великою пропускною здатністю. Відповідно програми можуть працювати повільніше ніж на локальному комп'ютері. На думку провідних російських ІТ-компаній, основною перешкодою широкому розвитку хмар, є відсутність широкосмугового доступу в Інтернет (ШСД) – насамперед у регіонах.

 

Безпека.

 

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

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

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

Функціональність «хмарних» додатків. Не всі програми або їх властивості доступні віддалено. Якщо порівнювати програми для локального використання і їх «хмарні» аналоги, останні поки програють у функціональності. Наприклад, таблиці Google Docs або програми Office web application мають набагато менше функцій і можливостей, ніж Microsoft Excel.

Залежність від «хмарного» провайдера.

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

Деякі експерти, наприклад Г. Маклеод (Hugh Macleod) у статті «Найбільш добре охороняється секрет Хмар», стверджують, що хмарні обчислення ведуть до створення величезної, небаченої раніше монополії. Чи можливо це ? Звичайно, на ринку хмарних обчислень для приміщення в хмару якої інформації, у відношенні якої існують правила інформаційної безпеки, компанії будуть скоріше використовувати таких вендорів, чиє ім'я «на слуху» і кому вони довіряють. Таким чином, існує певна небезпека того, що всі обчислення і дані будуть агреговані в руках однієї сверхмонополіі. Проте на даний момент на ринку вже існують кілька компаній з приблизно однаковим високим рівнем довіри з боку клієнтів (Microsoft, Google, Amazon), і немає ніяких фактів, які б вказували на можливість домінування однієї підприємством всіх інших. Тому в найближчому майбутньому поява глобальної сверхкомпаніі, яка буде координувати і контролювати всі обчислення в світі, дуже малоймовірно, хоча одна лише можливість такої події відлякує деяких клієнтів.

 

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

 

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

Канали зв'язку в більшості регіонів країни характеризуються відсутністю SLA за якістю наданого сервісу (QoS), що особливо відноситься до останніх милям. Що толку від того, що ваш основний трафік йде по магістралі з гарантованим QoS (зі своїми обмеженнями), якщо кінцеві умови підключені до неї через місцевого оператора, навіть не чула про таку проблему. При цьому вартість зв'язку для великих організацій може складати до 50 % від ІТ-бюджету. Відповідно перехід до хмарної моделі істотно впливає на мережеву топологію ваших потоків даних і, швидше за все, QoS буде гірше ніж у внутрішній мережі. Або що б отримати якість обслуговування на прийнятному рівні доведеться заплатити стільки грошей, що вся економія від централізації інфраструктури або додатків буде перекреслена зростанням комунікаційних витрат.

Безпека. Проблема безпеки є серйозним стримуючим фактором. Нерідко Служби Безпеки створюють досить високий загороджувальний бар'єр для ідеї винести будь-які дані за периметр своєї мережі. Часто без якої нормальної аргументації.

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

Розподілені обчислення (grid computing)

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

Встановлення загального протоколу в мережі Інтернет безпосередньо призвело до швидкого зростання онлайн користувачів. Це призвело до необхідності виконувати більше змін в поточних протоколах і до створення нових. На поточний момент широко використовується протокол Ipv4 (четверта версія IP протоколу), але обмеження адресного простору, заданого ipv4, неминуче призведе до використання протоколу ipv6. Протягом довгого часу удосконалилося апаратне і програмне забезпечення, в результаті чого вдалося побудувати загальний інтерфейс в Інтернет. Використання веб-браузерів призвело до використання моделі «Хмари», замість традиційної моделі інформаційного центру.

На початку 1990-их, Іен Фостер і Карл Кесселмен представили їх поняття Грід обчислень. Вони використовували аналогію з електричною мережею, де користувачі могли підключатися і використовувати послугу. Грід обчислення в чомусь спираються на методах, що використовуються в кластерних обчислювальних моделях, де багаторазові незалежні групи, діють, як мережа просто тому, що вони не всі розташовані в межах тієї ж області.

Зокрема, розвиток Грід технологій дозволило створити так звані GRID – мережі, в яких група учасників могла спільними зусиллями вирішувати складні завдання. Так, співробітники IBM створили інтернаціональну команду grid – обчислень, що дозволила істотно просунутися в області боротьби з вірусом імунного дефіциту. Цілі команди з різних країн приєднували свої обчислювальні потужності і допомогли «обрахувати» і змоделювати найбільш перспективні форми для створення ліків від СНІДу...»

На практиці межі між цими (grid і cloud) типами обчислень досить розмиті. Сьогодні з успіхом можна зустріти «хмарні» системи на базі моделі розподілених обчислень, і навпаки. Однак майбутнє хмарних обчислень все ж значно масштабніше розподілених систем, до того ж не кожен «хмарний сервіс» вимагає великих обчислювальних потужностей з єдиної керуючої інфраструктурою або централізованим пунктом обробки платежів.

Короткі підсумки:

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

Ключові терміни:

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

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

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

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

Приватна хмара – це варіант локальної реалізації «хмарної концепції», коли компанія створює її для себе самої, в рамках однієї організації.

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

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

Лекція 9. Веб-служби в Хмарі

 

Коротка анотація лекції:

Розглянемо деякі з веб-служб, що надаються концепцією хмарних обчислень. Інфраструктура є послугою в концепції хмарних обчислень. Є багато різновидів управління інфраструктурою в хмарному середовиші. «Інфраструктура як Сервіс» (Infrastructure – as-a-Service, IaaS) в основному за запитом на базі сучасних обчислювальних технологій і високошвидкісних мереж. «Комунікацій як Сервіс»(Communication-as-a-Service, CaaS).»Програмне забезпечення як Сервіс «(Software-as-a-Service, SaaS), такі як Amazon.com з їх еластичною платформою хмари, характеристики, переваги, та архітектурний рівень обслуговування. Досліджуємо ключові особливості використання зовнішніх джерел/ресурсів (outsourcing), доступні як «Платформи як Сервіс»(Platforms-as-a-Service, PaaS).

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

Мета лекції:

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

Текст лекції:

Інфраструктура як Сервіс (IaaS)

 

Інфраструктура як Сервіс (Infrastructure-as-a-Service, IaaS)–надання комп'ютерної інфраструктури (як правило, це платформи віртуалізації) як сервісу. IaaS посилює технологію, послуги і вкладення в центри обробки даних, щоб надати це як послугу клієнтам. На відміну від традиційного аутсорсингу, який вимагає належної старанності, нескінченних переговорів і складних, довгих контрактів, IaaS зосереджена навколо моделі надання послуг, яка забезпечує зумовлену, стандартизовану інфраструктуру, безумовно оптимізовану під потреби клієнта. Спрощені пропозиції роботи і вибір рівня сервісного обслуговування полегшує клієнтові вибір рішення з певним набором основних експлуатаційних характеристик. Як правило, постачальники надають компоненти наступних рівнів:

•Апаратне забезпечення (як правило, Грід з масивною горизонтальною масштабованістю);

•Комп'ютерна мережа (включаючи маршрутизатори, брандмауери, балансування навантаження і т.д.);

•Підключення Інтернет;

•Платформа віртуалізації для того, щоб запускати віртуальні машини;

•Угоди сервісного обслуговування;

•Інструменти обліку обчислень.

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

•Вільний доступ до попередньо сконфігурованого середовища;

•Використання інфраструктури останнього покоління;

•Захищені і ізольовані обчислювальні платформи;

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

•Здатність керувати піковими навантаженнями;

•Більш низькі витрати;

•Менший час, вартість і складність при додаванні або розширенні функціональності.

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

 

Рисунок 9.1 Грід обчислення

 

Amazon

Розглянемо один з прикладів–Amazon's Elastic Compute Cloud (Amazon EC2). Amazon EC2 – веб-служба, яка забезпечує обчислювальні потужності порядкового розміру в хмарі. Це розроблено, щоб зробити веб-обчислення доступнішими для розробників і щоб запропонувати безліч переваг для клієнтів:

•Інтерфейс веб-служби, дозволяє клієнтам отримувати і формувати простір з мінімальним зусиллям;

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

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

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

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

Amazon EC2 представляє обчислювальне навколишнє середовище, дозволяючи клієнтам використовувати веб інтерфейс, для отримання та управління послугами, необхідними для запуску одного або більше примірників операційної системи. Клієнти можуть завантажити навколишнє середовище з їх налаштованими додатками. Вони можуть керувати мережевими правами доступу і так багато систем, скільки їм потрібно. Для використання Amazon EC2, клієнтам спочатку необхідно створити Amazon Machine Image (AMI). Цей образ містить додатки, бібліотеки, дані та пов'язані параметри конфігурації, використовувані в віртуальному обчислювальному середовищі. Amazon EC2 пропонує використання попередньо сконфігуровані образи, створені з шаблонами, необхідними для негайного запуску. Коду користувачі визначили і формували їх AMI, вони використовують інструменти Amazon EC2 для завантаження образу в Amazon S3. Amazon S3 – склад, який забезпечує безпечний, надійний і швидкий доступ до клієнта AMI. Перш, ніж клієнти зможуть використовувати AMI, вони повинні використовувати веб інтерфейс Amazon EC2 для налаштування безпеки і мережевий доступ.

Під час конфігурації користувачі вибирають, який тип категорії і яку операційну систему вони хочуть використовувати. Доступні типи категорій складають дві різні категорії: Стандартний процесор або High-CPU процесор. Більшості додатків найкраще задовольняє стандартний випадок, в який входять маленький, великий і дуже великий примірники платформи. У разі High-CPU використовується пропорційно більше ресурсів центрального процесора, ніж пам'яті довільного доступу (RAM), що більш підходить високонавантажених додаткам. У разі High-CPU процесора для вибору є середня і дуже велика платформи. Після визначення, яку сутність використовувати, клієнти можуть запустити, завершити, і контролювати так багато примірників їх AMI, скільки необхідно при використанні інтерфейсів прикладного програмування веб-служби (API) або велику різноманітність інших інструментів управління, якими здійснюється обслуговування. Користувачі можуть вибрати, чи хочуть вони запускати додатки в різних центрах обробки даних, використовувати статичні IP адреси кінцевих точок, при цьому вони платять тільки за фактично споживані ресурси. Користувачі також можуть вибрати доступні AMI з бібліотеки. Наприклад, якщо необхідний звичайний Linux сервер, то клієнтом може бути один із стандартних Linux збірок AMIs.

Є досить багато особливостей сервісу EC2, які забезпечують суттєві переваги для підприємства. Насамперед, Amazon EC2 забезпечує фінансову вигоду. Через великий масштаб компанії Amazon і великої клієнтської бази, це недорога альтернатива багатьом іншим можливим рішенням. Витрати понесені на запуск і керування розділені між великою кількістю клієнтів, роблять вартість для будь-якого клієнта набагато нижче, ніж будь-яка інша альтернатива. Клієнти платять дуже низький відсоток за обчислювальні потужності, які вони фактично споживають. Безпека також забезпечена через інтерфейси веб-служби Amazon EC2. Ці інтерфейси дозволяють користувачам формувати параметри налаштування брандмауера, які контролюють мережевий доступ до і між групами примірників служб. Amazon EC2 пропонує дуже надійне середовище, де випадки заміни можуть бути швидко забезпечені.

•Динамічна Масштабованість.

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

•Повний контроль над екземплярами.

У користувачів є повний контроль над їх екземплярами. У них є повний доступ до кожного примірника, і вони можуть взаємодіяти з ними з будь-якої машини. Примірники можуть бути перезавантажені, віддалено використовуючи API веб-служби. Користувачі також мають доступ до консолі своїх примірників. Як тільки користувачі налаштували їх аккаунт і завантажили їх AMI в сервіс Amazon S3, їм необхідно тільки запустити екземпляр. Можливо запустити AMI на будь-якому числі примірників (або для будь-якого типу), викликавши RunInstances API, який підтримується Amazon.

•Гнучкість конфігурації.

Параметри налаштування конфігурації можуть значно відрізнятися серед користувачів. У них є вибір з різних типів екземплярів, операційних систем, і пакетів програмного забезпечення. Amazon EC2 дозволяє їм вибирати конфігурацію пам'яті, центрального процесора, і системи зберігання, яка оптимально підходить для їх вибору операційної системи та програми. Наприклад, вибір користувача операційної системи може також включати численні збірки Linux, Microsoft Windows Server, і навіть OpenSolaris, всі запущені на дійсних серверах.

•Інтеграція з Іншими Веб-службами Amazon.

Amazon EC2 працює в з'єднанні з безліччю інших веб – служб Amazon. Наприклад, Amazon Simple Storage Service (Amazon S3), Amazon SimpleDB, Amazon Simple Queue Service (Amazon SQS) і Amazon CloudFront всі інтегровані, щоб забезпечити повне рішення для обчислень, обробки запитів та зберігання між широким діапазоном додатків.

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

Amazon SimpleDB – інший веб сервіс, розроблений для того, щоб виконувати запити на структуровані дані Amazon Simple Storage Service (Amazon S3) в режимі реального часу. Цей сервіс працює в з'єднанні з Amazon EC2, щоб надати користувачам можливість зберігання, обробки і запитів наборів даних у межах навколишнього середовища хмари. Ці сервіси розроблені, щоб зробити веб масштабовані обчислення легше і більш прибутковими для розробників. Традиційно даний тип функціональності був забезпечений використанням кластерної реляційної бази даних, яка вимагає значних інвестицій. Впровадження даних технологій викликало більше складності і часто вимагало послуг адміністрування та підтримки бази даних.

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

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

Amazon CloudFront – веб-сервіс для доставки контенту (змісту). Amazon CloudFront інтегрується з іншими Amazon Web Services. Мета сервісу – дати розробникам і підприємствам простий спосіб поширюватиконтент для кінцевих користувачів з низькою затримкою, високою швидкістю передачі даних, при цьому не вимагаючи жодних зобов'язань. Запити об'єктів автоматично маршрутізіруются на найближча граничний сервер. Таким чином, зміст доставлено з кращою можливою продуктивністю. Граничний сервер отримує запит від комп'ютера користувача і з'єднується з іншим комп'ютером, викликаючи оригінальний сервер, де розташоване додаток. Коли оригінальний сервер виконує запит, він відправляє дані програми тому на граничний сервер, який передає дані назад комп'ютера клієнта, який виконував запит. Сервіс не є вільним для користування.

 

Платформа як Сервіс (PaaS)

 

Розвиток «хмарних» обчислень призвів до появи платформ, які дозволяють створювати і запускати веб-додатки. Платформа як сервіс (Platform as a Service, PaaS) – це надання інтегрованої платформи для розробки, тестування, розгортання і підтримки веб-додатків як послуги, організованої на основі концепції хмарних обчислень.

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

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

PaaS пропонує більш швидку, більш економічно вигідну модель для розробки та доставки додатків. PaaS забезпечує всю інфраструктуру для запуску додатків через Інтернет. Аналогічні сервіси надають велику кількість компаній, таких як Microsoft, Amazon.com, Google. PaaS заснована на моделі обліку ліцензій чи моделлю підписки, таким чином, користувачі платять тільки за те, що вони використовують. Пропозиції PaaS включають робочі процеси для створення додатків, розробки додатків, тестування, розгортання і розміщення. Також сервіси додатків, віртуальні офіси, командне співробітництво, інтеграцію баз даних, безпека, масштабованість, зберігання, працездатність, управління станом, інструментарій приладових панелей і багато іншого.

Головні особливості PaaS включають сервіси для розробки, тестування, розгортання, розміщення та управління додатками для підтримки життєвого циклу розробки додатків. Веб інтерфейси інструментів створення, як правило, забезпечують деякий рівень підтримки щоб ​​спростити створення користувацьких інтерфейсів, заснованих на таких технологіях як HTML, JavaScript та інших технологіях. Підтримка багатокористувацької архітектури допомагає уникнути проблем при розробці щодо використання додатків багатьма користувачами одночасно. Провайдери PaaS часто включають послуги для управління паралельною обробкою, масштабованість, відмовостійкість і безпекою. Інша особливість – це інтеграція з веб – службами і базами даних. Підтримка протоколу обміну структурованими повідомленнями в розподіленої обчислювальної середовищі (Simple Object Access Protocol, SOAP) та інших інтерфейсів дозволяють додаткам PaaS створювати комбінації веб – сервісів (які називають mashup) так само легко, як наявність доступу до баз даних і повторного використання послуг всередині приватних мереж. Здатність формувати та розповсюджувати код між спеціалізованими, зумовленими або розподіленими командами дуже збільшує продуктивність пропозицій вендорів PaaS. Інтегровані пропозиції PaaS забезпечують можливість для розробників, щоб найбільш добре розуміти внутрішню роботу їх додатків і поведінку користувачів при використанні інструментів, подібних приладової панелі, щоб розглянути внутрішні параметри, засновані на вимірах кількості паралельних з'єднань і т.д. Деякі пропозиції PaaS розширюють цей інструментарій, що дозволяє складати рахунки оплати за використання.

 

Microsoft Azure

 

Платформа корпорації Майкрософт Windows Azure (спочатку відома під назвою Azure Services Platform) – це група «хмарних» технологій, кожна з яких надає певний набір служб для розробників додатків. На рисунку 9.2 показано, що платформа Windows Azure може бути використана як додатками, що виконуються в «хмарі», так додатками, що працюють на локальних комп'ютерах.

 

Рисунок 9.2 – Платформа Windows Azure підтримує програми, дані та інфраструктуру, що знаходяться в «хмарі».

 

Платформа Windows Azure складається з наступних компонентів:

•Windows Azure. Забезпечує середовище на базі Windows для виконання додатків і зберігання даних на серверах в центрах обробки даних корпорації Майкрософт.

•SQL Azure. Забезпечує служби даних в «хмарі»на базі SQL Server.

•.NET Services. Забезпечують розподілену інфраструктуру для «хмарних»додатків і локальних додатків.

 

Кожен компонент платформи Windows Azure відіграє власну роль.

На високому рівні зрозуміти Windows Azure дуже легко. Це платформа для виконання додатків Windows і зберігання їх даних в Інтернеті («хмарі»). На рисунку 9.3 показані її основні компоненти.

 

Рисунок 9.3 – Windows Azure надає «хмарним» програмам служби для обчислення і зберігання на базі Windows

 

Як показано на рисунку, Windows Azure виконується на великій кількості комп'ютерів, розташованих у центрах обробки даних корпорації Майкрософт, і доступний через Інтернет. Загальна структура підключення Fabric Windows Azure з'єднує безліч обчислювальних потужностей в єдине ціле. Служби Windows Azure з обчислення та зберігання побудовані на основі цієї структури.

Обчислювальна служба Windows Azur, працює на базі Windows. Для забезпечення первісної доступності цієї служби восени 2008 р. була відкрита для широкої публіки CTP-версія. Корпорація Майкрософт дозволила виконувати на Windows Azure тільки додатки, розроблені на платформі .NET Framework. Сьогодні, однак, Windows Azure також підтримує некерований код, дозволяючи розробникам виконувати програми, які розроблені не на базі .NET Framework. У будь-якому випадку такі додатки написані на звичайних мовах Windows – C#, Visual Basic, C++ та інших – за допомогою Visual Studio 2008 або інших засобів розробки. Розробники можуть створювати веб-додатки за допомогою таких технологій, як ASP.NET і Windows Communication Foundation (WCF), додатки, які виконуються як незалежні фонові процеси, або програми, що поєднують і те й інше.

Як додатки Windows Azure, так і локальні програми можуть отримувати доступ до служби сховища Windows Azure, роблячи це одним і тим же способом: за допомогою підходу RESTful. Однак Microsoft SQL Server не є базовим сховищем даних. Фактично сховище Windows Azure не відноситься до реляційних систем, і мова його запити не SQL. Оскільки воно спочатку призначено для підтримки додатків на базі Windows Azure, то забезпечує більш прості і масштабовані способи зберігання. Отже, воно дозволяє зберігати великі двійкові об'єкти           (binary large object – blob), забезпечує створення черг для взаємодії між компонентами додатків і навіть щось на зразок таблиць з простою мовою запитів. (Для тих додатків Windows Azure, яким потрібна звичайне реляційне сховище, платформа Windows Azure надає базу даних SQL Azure, описану далі.)

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

І все ж для отримання цих переваг потрібно ефективне управління. У Windows Azure кожен додаток має файл конфігурації, як показано на рис. 2. Змінюючи інформацію в цьому файлі вручну або за допомогою програми, власник додатку може контролювати різні аспекти його поведінки, такі як налаштування кількості примірників, які повинні виконуватися на платформі Windows Azure. Структура Fabric платформи Windows Azure спостерігає за тим, щоб додаток підтримувалося в необхідному стані.

Щоб дозволити своїм замовникам створювати, налаштовувати програми та спостерігати за ними, Windows Azure надає портал, доступний за допомогою браузера. Замовник надає Windows Live ID, а потім вирішує, створювати йому обліковий запис розміщення для виконання додатків, обліковий запис зберігання для зберігання даних або і ту і іншу. Оплата використання програми замовниками може здійснюватися будь-яким зручним способом: за допомогою підписки, почасово або як-небудь інакше.

Windows Azure – це спільна платформа, яку можна використовувати в різних сценаріях. Наведемо кілька прикладів, всі вони описуються з урахуванням можливостей CTP-версії.

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

•Незалежні постачальники програмного забезпечення, що створюють версію програми як служби наявного локального додатку Windows, можуть розробити його на базі Windows Azure. Завдяки тому, що Windows Azure головним чином забезпечує стандартну середу Windows, переміщення бізнес-логіки програми на цю «хмарну» платформу не повинно створювати особливих проблем. Ще раз підкреслимо: розробка на базі наявної платформи дозволяє незалежним постачальникам ПЗ зосередити увагу на бізнес-логіці, тобто на тому, що дозволяє їм робити гроші, а не витрачати час на інфраструктуру.

•Компанія, що створює додаток для своїх замовників, може вибрати для його розробки платформу Windows Azure. У силу того що Windows Azure підтримує .NET, не представляє труднощів знайти розробників з відповідними навичками до того ж за розумну плату. Виконання програми в центрах обробки даних Microsoft звільняє підприємства від відповідальності і витрат на підтримку власних серверів, перетворюючи капітальні витрати в експлуатаційні витрати. Особливо якщо у додатку є періоди пікового навантаження (якщо це, наприклад, мережевий магазин квітів, які необхідно вручити під час загального ажіотажу 8 березня), надання корпорації Microsoft функції підтримки великий серверної бази, необхідної для цього, може виявитися економічно вигідним.

Виконання додатків в «хмарі» – один з найважливіших аспектів «хмарних» обчислень. За допомогою Windows Azure корпорація Microsoft забезпечує як платформу для виконання додатків, так і спосіб зберігання даних. У міру того, як зростає інтерес до «хмарних» обчислень, очікується створення ще більшої кількості програм Windows для цієї нової області.

Один з найбільш привабливих способів використання серверів, доступних через Інтернет, – це обробка даних. Мета SQL Azure – вирішити цю проблему, пропонуючи набір веб – служб для зберігання самої різної інформації і роботи з нею. У той час, як представники Microsoft заявляють, що поступово SQL Azure буде містити цілий ряд можливостей, орієнтованих на дані, включаючи створення звітів, аналіз даних та багато іншого, першими компонентами SQL Azure стануть база даних SQL Azure Database і засіб синхронізації даних Huron. Це наочно продемонстровано на рисунку 9.4.

 

Рисунок 9.4 –  SQL Azure обслуговує засоби в Інтернеті, орієнтовані на роботу з даними.

 

База даних SQL Azure Database (раніше відома під назвою SQL Data Service) забезпечує систему управління базами даних (СКБД) в Інтернеті. Ця технологія дозволяє локальним і веб – додаткам зберігати реляційні та інші типи даних на серверах Microsoft в центрах обробки даних Microsoft. Так само як при роботі з іншими веб-технологіями, компанія платить тільки за те, що використовує, збільшуючи і зменшуючи обсяг використання (і витрати) у міру виникнення необхідності в змінах. Використання бази даних в «хмарі» також змінює характер капітальних витрат: на місце інвестицій у жорсткі диски і ПЗ для СУБД приходять експлуатаційні витрати.

На відміну від служби сховища Windows Azure база даних SQL Azure розроблена на основі Microsoft SQL Server. Тим неменш в первісній CTP – версії 2008 року база даних SQL Azure Database не надавала традиційний реляційний підхід до даних. Враховуючи відгуки замовників, корпорація Microsoft вирішила внести відповідні зміни. Надалі база даних SQL Azure Database буде підтримувати реляційні дані, забезпечуючи середу SQL Server в «хмарі» з індексами, уявленнями, збереженими процедурами, тригерами і багатьом іншим. Доступ до цих даних можна отримати за допомогою ADO.NET і інших інтерфейсів доступу до даних Windows. Фактично додатки, які сьогодні отримують доступ до SQL Server локально, працюватимуть майже точно так само з даними в SQL Azure Database. Для роботи з цією інформацією в «хмарі» замовники можуть також використовувати локальне ПЗ, таке як служби звітів SQL Server.

У той час, як додатки можуть використовувати базу даних SQL Azure Database в значній мірі також, як локальну СУБД, вимоги до управління істотно скорочені. Замість того, щоб турбуватися про техніку, наприклад, забезпечувати моніторинг використання диска і обслуговування файлів журналу, замовник SQL Azure Database може зосередити увагу на тому, що дійсно важливо, на даних. Корпорація Microsoft буде відповідати за питання експлуатації. Крім того, так само як у випадку з іншими компонентами платформи Windows Azure, використання SQL Azure Database не складає труднощів. Потрібно просто зайти на веб – портал і надати необхідну інформацію.

Другий компонент SQL Azure був заявлений під назвою Huron Data Sync. Ця технологія, розроблена на основі Microsoft Sync Framework і SQL Azure Database, дозволяє синхронізувати реляційні дані в різних локальних СУБД. Власники даних можуть визначати, що саме має синхронізуватися, як повинні вирішуватися конфлікти і багато іншого.

Додатки можуть використовувати SQL Azure самими різними способами. Наведемо кілька прикладів.

•Додаток Windows Azure може зберігати дані в SQL Azure Database. Незважаючи на те, що Windows Azure забезпечує власне сховище, реляційні таблиці не входять до число пропонованих варіантів. Враховуючи те, що багато наявних програм використовують реляційне сховище, а багато розробників знають, як з ним працювати, значну кількість додатків Windows Azure, швидше за все, буде працювати з даними звичним способом, тобто з  SQL Azure Database. Для підвищення продуктивності замовники можуть вказати, що певний додаток Windows Azure повинно виконуватися в тому ж центрі обробки даних, де SQL Azure Database зберігає інформацію цього додатка.

•У невеликій компанії або підрозділі великої організації додаток може використовувати SQL Azure Database. Замість того, щоб зберігати дані в базі даних SQL Server або Access, що працює на комп'ютері під чиїмось столом, додаток може використовувати переваги надійного і стійкого до відмов «хмарного» сховища.

•Припустимо, виробник хоче зробити інформацію про продукт доступною для своєї дилерської мережі і безпосередньо для замовників. Розміщення даних в SQL Azure Database дозволить зробити їх доступними для додатків, що виконуються на стороні дилерів, і для орієнтованих на замовників веб-додатків, які виконуються на стороні виробника.

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

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

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

Спочатку відомі як BizTalk Services, служби.NET Services пропонують функції для вирішення спільних проблем інфраструктури при створенні розподілених додатків. На рисунку 9.5 показані їх основні компоненти.

 

Рисунок 9.5 – Служби.NET Services забезпечують інфраструктуру в «хмарі», яка може бути використана для веб-додатків і локальних додатків.

 

Служби .NET Services складаються з наступних компонентів.

Управління доступом. Все більше поширюється підхід до посвідчень, який полягає в тому, що кожен користувач повинен надати додатку маркер, що містить деякий набір тверджень. На підставі цих тверджень додаток вирішує, що раз – вирішено робити користувачеві. Ефективне здійснення цієї процедури в масштабах компанії вимагає федерації посвідчень, яка дозволяє приймати твердження, зроблені в одній області посвідчень, в іншій області. Може також знадобитися перетворення тверджень, що змінює їх при передачі з однієї області посвідчень в іншу. Служба управління доступом забезпечує реалізацію обох функцій на основі «хмари».

 

Шина служб. Представлення служб додатків в Інтернеті набагато важче, ніж може здатися. Завдання шини служб – спростити цю процедуру, дозволяючи додаткам надавати кінцеві точки веб – служб, доступ до яких може бути отриманий іншими додатками – локальними або працюють в «хмарі». Кожній наданій кінцевій точці присвоюється URI, який клієнти можуть використовувати для пошуку служби та отримання доступу до неї. Шина служб також вирішує проблему перетворення мережевих адрес і проходження через міжмережеві екрани без відкриття нових портів для наданих додатків.

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

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

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

Так само як у випадку Windows Azure, надається портал, доступний за допомогою браузера, щоб дати замовникам можливість використовувати служби .NET Services за допомогою Windows Live ID. Мета корпорації Microsoft, що досягається за допомогою .NET Services, абсолютно очевидна: забезпечити корисну «хмарну» інфраструктуру для розподілених додатків.

 

Програмне забезпечення як Сервіс (SaaS)

 

Програмне забезпечення як сервіс (Software as a service, SaaS) або програмне забезпечення на вимогу (Software on Demand, SoD) – бізнес-модель продажу програмного забезпечення, при якій постачальник розробляє веб-додаток і самостійно управляє ним, надаючи замовникам доступ до програмного забезпечення через Інтернет. Основна перевага моделі SaaS для споживача полягає у відсутності витрат, пов'язаних з установкою, оновленням і підтримкою працездатності обладнання працюючого на ньому програмного забезпечення. Програмне забезпечення як сервіс є моделлю розповсюдження програмного забезпечення, в якій додатки розміщені у вендора SaaS або постачальника послуг і доступні для клієнтів по мережі, як правило, Інтернет. Модель SaaS доставки додатків стає все більш і більш поширеною технологією, яка підтримує веб-служби і сервіс-орієнтовану архітектуру (SOA). SaaS також часто асоційована з моделлю ліцензування, коли оплата відбувається в міру отримання послуг. Тим часом, послуги широкосмугових мереж стали все більш і більш доступними, для підтримки доступу користувачів з більшої кількості місць по всьому світу.

Величезні успіхи, досягнуті постачальниками послуг Інтернету (ISP), щоб збільшити смугу пропускання і зберегти можливість використання більш потужних мікропроцесорів разом з недорогими пристроями зберігання даних. Це забезпечує величезну платформу для того, щоб проектувати, розгортати і використовувати програмне забезпечення через всі області бізнес і приватних обчислень. Додатки SaaS також повинні бути в змозі взаємодіяти з іншими даними й іншими додатками серед великого різноманіття навколишніх середовищ і платформ. Компанія IDC описує дві моделі поставки SaaS.

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

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

•Архітектурний Рівень 1 – Спеціальний/Настроюваний.

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

•Архітектурний Рівень 2 – Конфігуровання.

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

•Архітектурний Рівень 3 – Ефективність мульти орендатора.

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

•Архітектурний Рівень 4 – Масштабованість.

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

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

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

•Доставка додатків по моделі «один до багатьох», на противагу традиційної моделіодин до одного».

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

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

•Раціональне управління;

•Автоматизоване оновлення та виправлення;

•Цілісність даних в рамках підприємства;

•Спільна робота співробітників підприємства;

•Глобальна доступність.

Серверна віртуалізація може використовуватися в архітектурі SaaS замість або на додаток до підтримки багато режиму. Головна перевага платформи віртуалізації – збільшення продуктивності системи без необхідності в додатковому програмуванні. Ефект об'єднання спільного використання ресурсів і платформи віртуалізації в рішення SaaS забезпечує більшу гнучкість і продуктивність для кінцевого користувача.

 

Комунікація як Сервіс (CaaS)

 

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

•систему зв'язку, що забезпечує передачу мовного сигналу по мережі Інтернет або по будь-яким іншим IP-мережах (VoIP),

•обмін миттєвими повідомленнями (IM),

•відеоконференц-зв'язок.

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

Модель CaaS дозволяє діловим клієнтам вибірково розгортати засоби комунікацій і послуг на підставі оплати послуг в строк для використовуваних сервісів. CaaS розроблений на ціновій політиці загального призначення, яка надає користувачам всебічний, гнучкий і легкий у розумінні сервісний план. Згідно Gartner, ринок CaaS, як очікується, буде нараховувати $ 2,3 мільярда в 2011 році, з щорічним темпом зростання більше 105 %.

Сервісні пропозиції CaaS часто пов'язані і включають інтегрований доступ до традиційного голосу (або VoIP) і даних, додаткова функціональність об'єднаних комунікацій, такі як відео виклики, спільна робота, бесіди, присутність в реальному часі і передача повідомлень, телефонна мережа, місцева і розподілена голосові послуги, голосова пошта. CaaS рішення включає надлишкове перемикання, мережа, надмірність обладнання, WAN failover – що безумовно підходить до потреб клієнтів. Всі транспортні компоненти VoIP розташовані в географічно розподілених, безпечних інформаційних центрах для високої доступності і життєздатність. CaaS припускає гнучкість і масштабованість для дрібного і середнього бізнесу, чого найчастіше самі компанії не можуть забезпечити. Постачальники послуг CaaS підготовлені до пікових навантажень, надають послуги з розширення ємності пристроїв, станів чи області покриття на вимогу замовника. Пропускна здатність мережі та набори засобів можуть бути змінені динамічно, таким чином, функціональність йде в ногу зі споживчим попитом і ресурси, що знаходяться у власності постачальника не використовуються даремно. На відміну від постачальника послуг, перспектива клієнта фактично не приводить до ризику обслуговування застарілого обладнання, так як обов’язок постачальника послуг CaaS полягає в тому, щоб періодично модернізувати або замінювати апаратне і програмне забезпечення, щоб підтримувати платформу в технологічно актуальному стані.

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

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

•Рішення розміщення та управління

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

•Зручність керування та функціональність

Коли клієнти користуються послугами зв'язку на стороні постачальника послуг CaaS, вони платять тільки за необхідну функціональність. Постачальник послуг може розподіляти вартість послуг. Як зазначалося раніше, це сприяє більш економічному впровадження та використання загальної необхідної функціональності для клієнтів. Економія за рахунок зростання виробництва дозволяє постачальникам послуг здійснювати обслуговування досить гнучко, вони не прив'язані до єдиному постачальнику інвестицій. Постачальники послуг в змозі посилити рішення найкращих серед аналогічних постачальників, таких як Microsoft, Google, Amazon, Cisco, Nortel більш економічно.

•Немає витрат коштів на обладнання

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

•Гарантована безперервність бізнесу

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

 

Моніторинг як Сервіс (MaaS)

 

Моніторинг як Сервіс (Monitoring-as-a-Service, MaaS) забезпечує в хмарі безпеку, насамперед на бізнес платформах. За минуле десятиліття MaaS став все більш і більш популярним. З появою хмарних обчислень, популярність MaaS стала більше. Контроль безпеки зачіпає захист клієнтів – підприємств або уряду від кібер загроз. Служба безпеки відіграє важливу роль у забезпеченні та підтримці конфіденційнjсті, цілісністі, і доступності засобів ІТ. Однак час і обмежені ресурси обмежують заходи безпеки та їх ефективність для більшість компаній. Це вимагає постійної пильності безпеки інфраструктури і критичних інформаційних засобів. Багато промислових правил вимагають, щоб організації контролювали своє середовище безпеки, журнали серверів, та інші інформаційні засоби, щоб гарантувати цілісність цих систем. Однак забезпечення ефективного контролю стану безпеки може бути складним завданням, тому що воно вимагає передових технологій, кваліфікованих експертів з безпеки, і масштабовані процес, жоден з яких не є дешевим. Сервіси контролю стану безпеки MaaS пропонує контроль в реальному часі, в режимі 24/7 і практично негайні реагування по інцидентах через інфраструктуру безпеки. Ці сервіси допомагають захистити критичні інформаційні активи клієнтів. До появи електронних систем забезпечення безпеки, контроль стану безпеки і реагування залежали у великій мірі від людських ресурсів і людських здібностей, які обмежували правильність і ефективність контролюючих зусиль. За минулі два десятиліття, були розроблені інформаційні технології в системах забезпечення безпеки, які здатні взаємодіяти з центрами операційної безпеки (SOC) через корпоративні мережі, що значно змінило картину. Дані засоби включають дві важливі речі:

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

2. Досягнення більш низьких операційних витрат безпеки і більш висока ефективність засобів безпеки.

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

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

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

Лекція 10. Поняття обчислювального кластера

 

Обчислювальний кластер - це мультикомп’ютерна архітектура, яка може використовуватися для паралельних обчислень. Це система, зазвичай складається з одного серверного вузла і одного або більше клієнтських вузлів, з'єднаних за допомогою Ethernet або деякої іншої мережі. Побудована з готових промислових компонентів, на яких може працювати ОС Linux, стандартних адаптерів Ethernet і комутаторів. Вона не містить специфічних апаратних компонентів і легко відтворювана. Також використовує програмні продукти, такі як ОС Linux, середовища програмування Parallel Virtual Machine (PVM) і Message Passing Interface (MPI). Серверний вузол управляє всім кластером і є файл-сервером для клієнтських вузлів. Він також є консоллю кластера та шлюзом у зовнішню мережу. Великі системи кластера можуть мати більше одного серверного вузла, а також можливі спеціалізовані вузли, наприклад, консолі або станції моніторингу. Вони конфігуруються і управляються серверними вузлами і виконують тільки те, що наказано серверним вузлом. У бездисковій конфігурації клієнтів, клієнтські вузли навіть не мають IP-адрес або імен, поки їх не призначить сервер. У більшості випадків клієнтські вузли не мають клавіатур і моніторів, і можуть бути доступні лише через віддалене підключення.

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

В даному випадку побудова кластерного комп'ютера не самоціль, а засіб досягти більшої ефективності і продуктивності від певного роду наукової роботи. Існує певний клас задач, що вимагають продуктивності більш високої, ніж ми можемо отримати, використовуючи звичайні комп'ютери. У цих випадках з кількох потужних систем створюють HPC (High Perfomance Computing) кластер, що дозволяє розробку обчислення не тільки з різних процесорів, але і з різних комп'ютерів. Для завдань, що дозволяють дуже хороше розпаралелювання і не пред'являють високих вимог по взаємодії паралельних потоків, часто приймають рішення про створення HPC кластеру з великого числа малопотужних однопроцесорних систем. Найчастіше подібні рішення, при низькій вартості, дозволяють досягти значно більшої продуктивності, ніж продуктивність суперкомп'ютерів.

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

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

Вузли кластера: підходящим вибором в даний момент є системи на базі процесорів Intel Core 2 Duo або Intel Core 2 Quad. Варто встановити на кожен вузол не менше 1Gb оперативної пам'яті. Бажано 2-4Gb. Одну з машин слід виділити в якості центральної (консоль кластеру) куди можна (але не обов'язково) встановити досить великий жорсткий диск, можливо більш потужний процесор і більше пам'яті, ніж на інші (робочі) вузли. Робити консоль кластеру більш потужною машиною має сенс, якщо необхідно мати на цьому комп'ютері крім інтерфейсу командного рядка більш зручне операційне оточення, наприклад віконний менеджер (KDE, Gnome), офісні програми, програми візуалізації даних і т.п..

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

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

Важливо зазначити, що бібліотеки для паралельних обчислень MPICH / MPI є кросплатформними, то вибір операційної системи (Windows vs Linux) не важливий. Однак слід врахувати той факт, що Linux є помітно менш ресурсномісткою системою. Наприклад при використанні PelicanHPC GNU Linux система займає в оперативній пам'яті не більше 40Мб! Вся інша пам'ять доступна паралельній програмі. Це дуже важливий чинник у тому випадку, коли кластер використовується з метою моделювання процесів на як можна більш докладній сітці.

Можлива організація кластерів на базі вже існуючих мереж робочих станцій, тобто робочі станції користувачів можуть використовуватися в якості вузлів кластеру вночі і в неробочі дні. Системи такого типу називають COW (Cluster of Workstations). У цьому випадку реальним видається варіант, коли кластер будується на основі існуючого комп'ютерного класу. Подібні класи вже є в більшості навчальних або наукових установах і зазвичай скомплектована однотипними машинами, що  необхідні для кластеру. Проте зазвичай такі комп'ютерні класи працюють під операційною системою Windows і, ймовірно, для заміни її на Unix доведеться вирішити питання адміністративного плану і питання пов'язані з побудовою навчального процесу. Принципових перешкод для вирішення цих питань мабуть немає, оскільки Unix (конкретно Linux) має все необхідне програмне забезпечення для проведення навчального процесу чи наукової діяльності (компілятори, засоби розробки, офісні програми, програми роботи з зображеннями та візуалізації даних, засоби публікації).

Мережа: У найпростішому випадку для зв'язку між вузлами кластеру використовується один сегмент Ethernet (10Mbit/sec на витій парі). Проте дешевизна такої мережі, внаслідок колізій обертається великими накладними витратами на міжпроцесорний обміни, а хорошу продуктивність такого кластера можна чекати тільки на завданнях з дуже простою паралельною структурою і при дуже рідкісних взаємодіях між процесами (наприклад, перебір варіантів).

Для одержання гарної продуктивності міжпроцесорних обмінів використовують Fast Ethernet на 100Mbit/sec або Gigabit Ethernet. При цьому для зменшення числа колізій або встановлюють декілька "паралельних" сегментів Ethernet, або з'єднують вузли кластеру через комутатор (switch). Під паралельними сегментами мається на увазі така структура мережі, коли кожен вузол кластера має більше однієї мережевої карти, які за допомогою спеціальних драйверів об'єднуються в один віртуальний мережевий інтерфейс, що має сумарну пропускну спроможність. Для того, щоб уникнути проблем з конфігуруванням такого віртуального інтерфесом, слід використовувати однакові мережеві карти на всіх машинах кластеру. Крім того, кожна паралельна лінія такого інтерфесу повинна являти собою Ethernet-мережу побудовану на окремому (від інших паралельних їй ліній) комутаторі.

 

10.1 Будова кластера

 

         В загальному розгортання кластеру як такого - завдання актуальне та доволі не складне. Причому, для цього підійде будь-який дистрибутив. Який саме з дистрибутивів Linux ставити в якості базової ОС - не має значення. Ubuntu, Mandriva, Alt Linux, Red Hat, SuSE ... Вибір залежить тільки від уподобань користувача.

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

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

2.                Після інсталяції базової ОС на консолі кластера, якщо це не зроблено в процесі первісної установки, необхідно буде встановити необхідні компілятори (фортран, С) і всі необхідні бібліотеки, desktop environment (GNOME або KDE), текстові редактори і т.д., тобто перетворити цей комп'ютер в робочу станцію розробника.

3. Встановити з репозитарію або з вихідного пакет MPICH або OpenMPI.

4. Описати в /etc/hosts майбутні вузли вашого кластеру, в тому числі і консоль кластеру.

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

6. Встановити на консолі кластеру ssh-клієнт (обов'язково) та ssh-сервер (опціонально, якщо буде надаватися доступ до консолі кластеру по мережі).

7. На всіх вузлах кластера встановити операційну систему, бібліотеки, необхідні для виконання користувальницьких паралельних програм, встановити MPICH, NFS-client, ssh-server. Вузли кластера в цілях економії ресурсів повинні навантажуватися в runlevel 3, так що ставити туди GNOME або KDE не треба. Максимум - поставити ряд бібліотек, якщо вони потрібні для користувача.

8. Описати в /etc/hosts всіх вузлів кластера майбутні вузли вашого кластеру, в тому числі і консоль кластеру.

9. На всіх вузлах кластера необхідно автоматично при завантаженні монтувати розшарений ресурс. Причому, шлях до цього ресурсу повинен бути однаковий, як на консолі кластера, так і на його вузлах. Наприклад, якщо на консолі кластеру дати доступ каталогу /home/mpiuser/data, то на вузлах кластеру цей ресурс також має бути змонтований в /home/mpiuser/data.

10. На всіх вузлах кластера забезпечити безпарольний доступу по ssh для консолі кластеру.

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

Таким чином і в консолі кластеру та в його вузлах необхідно мати два мережевих інтерфейси (дві мережеві карти), відповідно, потрібно два набори світчів, не пов'язаних один з одним, і два набори мережевих реквізитів для цих інтерфейсів. Тобто, NFS працює, наприклад, в мережі 192.168.1.0/24, а обмін даними відбувається в мережі 192.168.2.0/24. І відповідно, у файлах /etc/exports і /etc/fstab повинні будуть бути прописані адреси з першої мережі, а у файлах /etc/hosts і в файлі machines.LINUX, що описують кластер - адреси з другої.

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

1. Наявна різницева сітка розміру R, обчислення на якій при використанні звичайного комп'ютера займають час T. Час T - критичний параметр. Нам хочеться істотно зменшити час обчислень, маючи R як константу.

2. Наявна різницева сітка розміру R, обчислення на якій при використанні звичайного комп'ютера займають час T. Час T - не критично. Нас цікавить збільшення розміру сітки понад наявною в одному комп'ютері пам'яті для більш детального рахунку, можливого отримання більш тонких ефектів і т.п.

         Всі обчислення на різницевій сітці мають один спільний і важливий для нас параметр: час однієї ітерації. У разі використання кластеру цей час складається з двох частин: час рахунку на сітці Titer і час обміну даними між вузлами Texch. Titer залежить тільки від потужності процесора. А ось Texch залежить вже від розміру різницевої сітки, кількості вузлів кластеру та пропускної здатності мережі. Наведу остаточний результат для випадку двухгігабітної мережі, розміру різницевої сітки 64 гігабіти і часі однієї ітерації 100 сек.

 

Рисунок 10.1 – Часова характеристика обрахунку даних

 

         На графіку вісь ординат - тимчасова характеристика, вісь абсцис - кількість вузлів кластеру.

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

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

 

Рисунок 10.2 – Часова характеристика обрахунку даних

 

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

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

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

 

10.2 Організація мережі обчислювального кластеру

 

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

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

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

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

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

 

         10.2.1 Мережеві карти

В якості мережевих адаптерів можна використовувати будь-які наявні в продажу карти, що підтримують роботу в стандартах 100BaseTx і GigabitEthernet. Що стосується списку переваг, то можна порекомендувати в першу чергу 3Com. Серед інших варіантів можна назвати Compex, Intel, Macronix, інші карти, підтримувані драйвером tulip, наприклад карти на чіпсетах DC21xxx. Особливо популярними при побудові кластерів явяляются плати на базі мікросхем Intel 21142/21143. Популярність цих карт викликана існуючим механізном високої продуктивності, в той час як їх ціна в порівнянні з конкуруючими пропозиціями зазвичай досить невелика. Що стосується мережевих карт фірми 3Com, то вони мають деякі переваги, помітно впливають на продуктивність мережевих комунікацій. Наведемо лише кілька прикладів можливостей апаратного забезпечення карт 3Com.

Розвантаження процесора при обчисленні контрольних сум TCP/UDP/IP. Звільняє центральний процесор від інтенсивних обчислень контрольних сум, виконуючи їх в самій мережевій платі. Тим самим підвищується продуктивність системи і час життя процесора.

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

Режим Bus mastering DMA: забезпечує більш ефективний обмін даними для зниження завантаження центрального процесора.

 

         10.2.2 Комутатори

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

         Комутатори та інші елементи мережевої структури використовуються для забезпечення комунікацій між процесорами, для підтримки паралельного програмування і різних функцій управління. Для паралельного програмування організації взаємодії між процесами (Inter Process Communication, IPC) широко використовується комутатор Myrinet-2000 - дуже швидкий, добре масштабований широкосмуговий пристрій.     

        

         10.2.3 Мережеве забезпечення кластеру.

Як вже говорилося, вузли кластеру можна зв'язати звичайним способом, використовуючи Ethernet-адаптери. З'єднання машин кластеру може виглядати так, як це показано на рисунку 10.3.

Рисунок 10.3 – З’єднання машин кластера

 

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

Інтерфейс користувача рівня для такого "злиття" каналів складається з двох програм: 'ifconfig' і 'ifenslave'. Перший мережевий інтерфейс конфігурується як зазвичай командою 'ifconfig'. Програма 'ifenslave' копіює установки першого інтерфейсу на всі інші додаткові інтерфейси. Цією ж командою можна при бажанні будь-які інтерфейси сконфігурувати в режимі Rx-only. 
         Для і програм, що виконуються на кластері, метод абсолютно прозорий. Єдине вплив, який він надає - збільшення швидкодії.

Застосування методу має деякі обмеження: всі приєднані машини повинні мати однаковий набір bonded networks, тобто не можна в одній машині використовувати 2х100BaseTx, а в іншій 10Base і 100BaseTx. Застосування методу складається з двох частин, необхідні зміни Кернел для підтримки channel bonding, і програма ifenslave.


 

         10.2.4 Мережева файлова система

         Однією з особливостей запуску MPI-програм є необхідність наявності копій програми на всіх вузлах кластера, на яких вона виконується. Наприклад, якщо програма myprog розташована в каталозі /home/mpiuser/program1, то на всіх вузлах кластера повинен бути присутнім цей каталог і в нього повинна бути поміщена програма.

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

Для позбавлення від подібних проблем використовуються мережеві файлові системи. Існує велика кількість реалізацій таких систем, як платних, так і поширюваних під ліцензією GPL. Розглянема мережеву файлову систему NFS, наявну в будь-якому Linux-дистрибутиві загального призначення. Файлова система NFS - це аналог того, що йпродукт Майкрософт відомий під назвою windows share.

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

 

10.2.5 Конфігурація сервера

Для забезпечення мережевого доступу вузлів кластеру до розшарених на сервері кластеру ресурсів необхідно спочатку вирішити підключення nfs-клієнтам до nfs-сервера. Далі будемо припускати, що вузли кластера мають ip-адреси в діапазоні 192.168.1.2-192.168.1.254. Консоль кластеру, до каталогів файлової системи до якої ми будемо підключатися через NFS, має ip-адреса 192.168.1.1. Для дозволу мережевого доступу до NFS з цих адрес у файлі /etc/hosts.allow прописуємо наступну рядок:

portmap: 192.168.1.1

Крапка в кінці рядка обов'язкова. Далі слід визначити до якого каталогу ми дозволяємо мережевий доступ. Тобто, якому каталогу давати доступ. Приміром, необхіднозабезпечити у вузлах кластеру доступ до каталогу /home/mpiuser/data-and-progs. Для цього у файлі /etc/exports прописуємо рядок:

/Home/mpiuser/data-and-progs 192.168.1.0/255.255.255.0 (rw,no_root_squash)
         На цьому налаштування серверної частини закінчено. Щоб зміни вступили в силу необхідно перезапустити службу NFS за допомогою команди "service portmap restart".

 

10.2.6 Конфігурація клієнтів

Переходимо від сервера кластера (консолі кластера) до решти вузлів. Все що буде описано нижче необхідно виконати на кожному комп'ютері кластеру крім консольного.

Для підключення будь-якої файлової системи (розділу диска, мережевого ресурсу) використовується команда mount, якщо підключення відбувається вручну, або запис у файлі /etc/fstab, якщо підключення відбувається в момент завантаження системи. Нас буде цікавити останній випадок.

Для забезпечення запуску mpi-програм нам потрібно, щоб вміст каталогу /home/mpiuser/data-and-progs на вузлах кластеру збігався з вмістом цього ж каталогу на консолі кластеру. Для цього необхідно в домашньому каталозі користувача mpiuser (/home/mpiuser) створити порожній каталог data-and-progs. Після чого прописати у файлі /etc/fstabтакий рядок:

192.168.1.1: /home/mpiuser/data-and-progs/home/mpiuser/data-and-progs nfs rw 0 0

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

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

 

         10.2.7 SSH, беспарольный доступ

Розглянемо процедуру створення безпарольного доступу користувача user1 з консолі кластера на вузли кластеру по протоколу SSH. Безпарольний доступ забезпечитьбільш комфортну роботу в паралельній віртуальній машині. Так, відпаде необхідність вводити паролі доступу при додаванні в віртуальну машину кожного нового вузла і при копіюванні виконуваних модулів в локальні файлові системи вузлів кластеру.

Алгоритм забезпечення безпарольного доступу наступний: 
         1. Логін до консолі кластера: ssh user1@server 
         2. Переходимо в каталог ssh: cd ~ /. Ssh 
         3. Генеруємо rsa-ключі: ssh-keygen-t rsa 
         4. На питання задати ім'я файлу тиснемо Enter - залишається ім'я за замовчуванням id_rsa. 
         5. На прохання поставити пароль тиснемо Enter два рази (другий раз для перевірки). 
         6. Копіюємо публічний ключ на вузол кластеру: scp id_rsa.pub user1@node1: ~ /.Ssh

         7. Логіном до вузла node1: ssh user1@node1 
         8. Переходимо в каталог ssh: cd ~ /.Ssh 
         9. Копіюємо публічний ключ: cat id_rsa.pub>> authorized_keys2 
         10. Відключаємося від вузла node1 
         11. Повторюємо пункти 6-10 для інших вузлів кластера (node2 ... nodeN)

Після проведення описаної процедури користувач "user1" зможе підключатися до вузлів кластеру з консолі кластера не вводячи свій пароль. Слід зазначити, таким чиномзабезпечується безпарольний доступ лише для одного користувача і лише в одному напрямку: консоль кластеру -> вузли кластеру. І тільки для випадку, коли user1 підключається до вузлів кластеру під своїм ім'ям.

 

         10.3 Розпаралелювання програм

 

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

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

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

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

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

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

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

 

         10.3.1 Варіанти декомпозиції

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

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

Існує три основні варіанти декомпозиції: проста декомпозиція (trival), функціональна (functional) і декомпозиція даних. Питання про використання того чи іншого типу декомпозиції при написанні паралельної програми вирішується виходячи зі структури самого завдання. Причому, в залежності від умов, можна використовувати відразу декілька типів.

 

         10.3.2 Тривіальна декомпозиція

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

Рисунок 10.4 – Приклад тривіальної декомпозиції

 

         10.3.3 Функціональна декомпозиція

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

Припустимо наше завдання зводиться до застосування якогось функціонального оператора до великого масиву даних: S = F (a ). Припустимо також, що виконання функції F над одним елементом масиву займає досить великий час і нам хотілося б цей час скоротити. У цьому випадку ми можемо спробувати уявити вихідну функцію як композицію декількох фунуцій: S (a ) = I (H (R (a ). Зробивши декомпозицію ми отримаємо систему послідовних завдань:

x = r (a );

y = h (x);

= i (y);

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

 

 

Рисунок 10.5 – Приклад функціональної декомпозиції

 

У цього методу декомпозиції є пара особливостей, про які треба пам'ятати. 
Перша особливість полягає в тому, що вихід кластеру на максимальну ефективність відбувається не відразу після запуску завдання, а поступово, у міру того, як відбувається часткова обробка першого елемента масиву. Другий і третій процесори в нашому прикладі, які відповідають за виконання функцій g(x) і f(y), будуть простоювати до тих пір, поки не закінчиться виконання функції h(a[1]) на першому процесорі. Третій процесор буде простоювати до закінчення виконання функції g(a[1]). За аналогічним сценарієм, тільки в дзеркальному відображенні, відбувається закінчення роботи.

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

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

 

 

10.3.4 Декомпозиція даних

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

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

 

         10.3.5 Regular Domain Decomposition

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

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

 

Рисунок 10.6 – Регулярна декомпозиція вихідної решітки

 

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

 

         10.3.6 Сітка процесів

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

 

 

Рисунок 10.7 – Глобальний набір даних декомпозиції

 

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

 

10.3.7 Зміна елементів даних

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

 

10.3.8 Область перекриття

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

 

 

Рисунок 10.8 – Область процесу перекриття

 

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

 

10.3.9 Граничний обмін

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

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

 

 

Рисунок 10.9 – Процеси граничного обміну

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

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

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

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

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

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

3) Виконуємо обробку даних.

Процес здійснення та прийому даних від інших процесів називається "граничний обмін".

 

10.3.10 Деталізація

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

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

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

          10.4 Паралельна віртуальна машина (PVM)

 

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

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

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

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

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

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

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

        

10.4.1 Взаємодія завдань у PVM

У системі PVM кожне завдання, запущене на деякому процесорі, ідентифікується цілим числом, яке називається ідентифікатором завдання (TID) і за змістом схоже на ідентифікатор процесу в операційній системі Unix. Система PVM автоматично підтримує унікальність таких ідентифікаторів: копії одного виконуваного файлу, запущеного паралельно на N процесорах PVM, створюють N завдань з різними TID.

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

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

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

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

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

 

         10.4.2 Управління завданнями

Управління завданнями в PVM здійснюється на основі деякого набору функцій. Існує два варіанти написання паралельних завдань для PVM. У першому варіанті весь виконуваний на всіх процесорах код пишеться як одне велике завдання. Відповідно на кожному процесорі запускається на виконання один і той же файл. Зазвичай на самому початку своєї роботи програма викликає функцію call pvmfmytid (tid), повертає значення ідентифікатора завдання tid> = 0, яким може визначатися вибір для виконання тієї чи іншої частини програми. Ця функція може викликатися більше одного разу.

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

call pvmfspawn (task, flag, where, ntask, tids, numt);

task - ім'я виконуваного файлу;

INTEGER flag - опції запуску;

where - вказує місце запуску;

INTEGER ntask - число запусщених копій програми;

INTEGER tids - масив значень tid для запущених завдань.

Ця функція запускає в PVM ntask копії виконуваного файлу з ім'ям "task" з однаковими аргументами командного рядка в масиві argv і повертає число запущених завдань numt а також послідовність ідентифікаторів для запущених завдань. Другий варіант написання паралельного завдання полягає в тому, що для кожного процесора пишуться свої власні завдання, що виконують різні дії, і створюється маленька програма, яка, використовуючи функцію pvm_spawn запускає всі інші завдання.

Виконуваний файл для функції pvm_spawn () повинен перебувати в строго визначеному каталозі. Під Unix завдання шукається в каталогах $PVM_ROOT/bin/$PVM_ARCH/ і $HOME/pvm3/bin/ $PVM_ARCH. Задавати ім'я каталогу в параметрі "task" неприпустимо.

Але це не єдиний спосіб. В іншому варіанті виконуваний файл шукається (і запускається) не тільки на тому комп'ютері, на якому працює викликане pvm_spawn () завдання, але в залежності від параметрів flag і where, на будь-якому вхідному до складу PVM. Наприклад, якщо flag == 0, то PVM сам вибирає, на якій з машин запускати нові завдання (головне, щоб додаток був скомпільовано на цих машинах); а якщо flag & PvmMppFront> 0, то місцем запуску буде обраний найшвидшийкомп'ютер.

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

FORTRANe flag може бути сумою таких величин:

PVMDEFAULT = 0 - PVM може вибрати будь-яку машину для старту завдання,

PVMHOST = 1 - параметр where визначає машину для запуску,

PVMARCH = 2 - параметр where визначає тип архітектури,

PVMDEBUG = 4 - процес стартує під відгадчиком,

PVMTRACE = 8 - процес генерує PVM trace data.

Параметр where описує на яких комп'ютерах кластера може бути запущене завдання. Параметр є простою строковою змінною, в яку записано ім'я списку комп'ютерів. Списки комп'ютерів знаходяться у конфігураційних файлах системи PVM і формуються на етапі її установки. Наприклад у випадку, коли у вашому кластері крім консольної машини присутній ще два комп'ютери: один класу P166 та іншой класу P4, ви можете визначити їх в системі під іменами "oldcomp" і "supercomp". І залежно від тих або інших умов, запускати свої завдання на якусь з машин кластеру.

І, нарешті, ще дві функції, пов'язані з управлінням завданнями:

call pvmfkill (tid, info)

call pvmfexit (info)

Перша з них завершує виконання завдання з ідентифікатором tid, повертаючи при помилці код info <0. Відзначимо, що завдання не може таким чином завершити своє виконання. Друга функція завершує роботу PVM, запущеної користувачем, але при цьому сама задача продовжує виконуватися вже як звичайне локальне завдання і завершує роботу звичайним чином.

 

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

Здійснення повідомлень в PVM призначена для передачі даних між різними процесами і складається з трьох кроків. По-перше, буфер даних перед посиланямповинен бути ініціалізований першим з використанням функцій pvm_initsend () або pvm_mkbuf (). По-друге, дані, що пересилаються повинні бути упаковані в цей буфер. Для пакування використовується деяка кількість комбінацій викликів функції pvm_pk * (). У FORTRAN упаковка даних проводиться підпрограмою pvmfpack (). Третій крок полягає у пересиланні даних адресатам. Для цієї мети в залежності від списку адресатів використовується виклик функції pvm_send (), в параметрах якихвказується конкретний процес-приймач, або функції pvm_mcast (), що використовується для всеспрямованої передачі.

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

1) Для прийому будь-яких повідомлень.

2) Для прийому будь-яких повідомлень від певного джерела.

3) Для прийому будь-яких повідомлень з певним message tag.

4) Для прийому будь-яких повідомлень з певним message tag з певного джерела.

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

Буфер повідомлення call pvmfinitsend (encoding, bufid).

Якщо користувач використовує тільки один буфер повідомлення, то єдина необхідна для роботи з буфером функція - це pvm_initsend (). Ця функція викликається безпосередньо перед упаковкою нової порції пересилаючих даних в буфер повідомлення. Функція pvm_initsend звільняє буфер і створює новий для пакування в нього даних. Схема кодування упаковується в буфер даних і вказується завданням змінної encoding. Повернене в змінну bufid значення є ідентифікатором буфера.

Мінлива encoding може приймати такі значення:

1)