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

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

БД 2 -mike

Лекція 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, після чого пере-слать отриманий результат в Глазго для відбору кортежів по ус-ловию MaxPrice >  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.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 Base Connectivity), та 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, є продуктом компанії JavaSoft і реалізує розподілену модель. 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 SkeletonInterfaceспільні інтерфейси для об’єктів, незалежно від їх типу, які не були визначені в 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 Object Request 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 - підтримка інтерфейсів сервісів високого рівня, які можуть включати спеціалізацію ObjectServices. Тобто операції, представлені Common Facilities, призначені, зокрема, для використання Object Services та прикладними об’єктами. Це реалізується шляхом наслідування стандартних Інтерфейсів. Спільні засоби поділяються на горизонтальні та вертикальні. До горизонтальних сервісів відносяться такі спільні сервіси, як, наприклад, управління інформацією, задачами, всією системою, тобто засоби, які не залежать від конкретних прикладних систем. До вертикальних сервісів відносяться сервіси, специфічні для якоїсь діяльності, наприклад, медицина, фінанси.

Application Objects. Об’єкти, якщо вони приймають участь в обміні з ORB з використанням IDL. Як правило, додатки складаються з кількох бізнес-об’єктів, що взаємодіють. Додатки-об’єкти будуються поверх ORB, які надаються ORB, CommonFacilities та Object Facilities сервісів. Сутність для замовників (або системних інтеграторів) полягає в тому, щоб зібрати різні бізнес-об’єкти до одної системи, причому, поза залежністю від виробника.

CORBA та WWW. Відповідь на поставлене раніше питання - як об’єднати ІС, засновані на технології WWW, з іншими (в тому числі розподілені) ІС - полягає в наступному: слід пов’язати технологію розподілених об’єктів (тобто технологію CORBA) з технологією WWW. Метою такої роботи є детальний розгляд зв’язки CORBA та WWW. Питання впровадження CORBA в ІС виходить за рамки курсу. Є два рішення такої задачі, перше - будується на застосуванні технології CGI, а друге - на застосуванні технології Java. Досліджено практичне застосування цих технологій, з використанням продуктів Orbix та OrbixWeb від IONATechnologies.

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, якому ви довіряєте. Якщо з'ясується що CABAR знаходиться у вашому “довіреному списку”, це означатиме, що свідоцтво 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 будують глобальні мейнфрейми, а хтось під власні потреби створює приватні хмари, які є тими ж мейнфреймами, але меншого масштабу. Залишається припустити, що попереду є винахід інтегральної схеми і мікропроцесора.

 

Короткі підсумки:

 

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

 

Ключові терміни:

 

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

Блейд сервер - комп'ютерний сервер з компонентами, винесеними і узагальненими в кошику для зменшення займаного простору.

Система Зберігання Даних (СЗД) - це програмно - апаратне рішення з організації надійного зберігання інформаційних ресурсів та надання до них гарантованого доступу.

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

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

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

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

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

Короткі підсумки:

У даній лекції була розглянута технологія надання веб – сервісів «інфраструктура як сервіс». Був отриманий базовий матеріал про технології провідних вендорів Amazon і Microsoft.

Ключові терміни:

Інфраструктура як Сервіс, IaaS – надання комп'ютерної інфраструктури (як правило, це платформи віртуалізації) як сервісу.

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

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

Комунікація як Сервіс, CaaS – побудоване в хмарі комунікаційне рішення для підприємства MaaS.

Лекція 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 або GigabitEthernet. При цьому для зменшення числа колізій або встановлюють декілька "паралельних" сегментів 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) PvmDataDefault - XDR кодування, що використовується в PVM за замовчуванням. Це кодування використовується зазвичай в гетерогенних кластерах, коли PVM не може знати чи розуміє приймаюча сторона відповідний формат даних. Наприклад, коли дані передаються з Linux-машини на Windows-машину. У випадку, коли в кластері використовується тільки один тип операційної машини або коли користувач впевнений, що приймаюча сторона зрозуміє все правильно, слід використовувати тип кодування PvmDataRaw.

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

3) PvmDataInPlace - дані залишаються на місці, не переміщаючись в буфер посилки. Цей тип кодування можна використовувати для зниження накладних витрат, пов'язаних з переміщенням даних в буфер. У цьому випадку буфер містить тільки довжини і покажчики на дані, що передаються. При виклику pvm_send () дані копіюються безпосередньо з того місця, де вони знаходяться. Використання цього кодування накладає одне обмеження. Передані дані не повинні бути змінені між моментом, коли почалася їх упаковка і моментом закінчення передачі буфера повідомлення адресату. Однак, при використанні даного типу упаковки, є одна помітна перевага. Функція упаковки pvm_initsend може бути викликана тільки один раз на початку програми. Наприклад на початку роботи програми ми можемо упакувати дані з області перекриття і передавати їх безліч разівв міру необхідності.

 

 10.4.4 Архівування даних

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

call pvmfpack (what, xp, nitem, stride, info)

У пареметрі what вказується тип упаковуваних даних. Параметр xp є першим елементом масиву даних. Пареметри nitem і stride описані вище. Параметр info - повертає значення. Значення параметра what представлені наступним чином:

STRING 0 REAL4 4

BYTE1 1 COMPLEX8

INTEGER2 2 REAL8

INTEGER4 3 COMPLEX16 7

Константи, відповідні значенням параметра what визначені у файлі pvm3/include/fpvm3.h. Деякі виробники можуть розширювати цей список додатковими даними, наприклад INTEGER8, REAL16 та ін.

Приклад використання всіх цих функцій:

CALL PVMFINITSEND (PVMRAW, INFO)

CALL PVMFPACK (INTEGER4, NSIZE, 1, 1, INFO)

CALL PVMFPACK (STRING, `row 5 of NXN matrix ', 19, 1, INFO)

CALL PVMFPACK (REAL8, A (5,1), NSIZE, NSIZE, INFO)

CALL PVMFSEND (TID, MSGTAG, INFO)

Прийом і посилка даних

call pvmfsend (tid, msgtag, info)

call pvmfmcast (ntask, tids, msgtag, info).

Функція pvm_send () позначає повідомлення тегом msgtag і виконує негайну пересилку даних процесу з відповідним ідентифікатором tid. Функція pvm_mcast () позначає повідомлення тегом msgtag і виконує негайну пересилку даних всім процесам, які мають ідентифікатори, співпадаючими зі значеннями, що зберігаються в масиві tids. Довжина масиву tids дорівнює ntask.

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

call pvmfpsend (tid, msgtag, xp, cnt, type, info)

Ці функції упаковують масив певним параметром type-типу в буфер і передають його процесу, ідентифікованого параметром tid. У FORTRAN типи даних визначені так само, як і для процедури pvmfpack ().

Система PVM містить кілька методів для організації прийому повідомлень. Причому відсутній послідовності функцій. Тобто немає такого обмеження, коли повідомлення, послане процедурою pvm_psend повинно бути обов'язково прийнято процедурою з ім'ям типу pvm_precv. Незалежно від того, як було надіслано повідомлення, прийнято воно може бути любим з можливих варіантів. Те ж зауваження стосується адресної і мультикастної (multicast) передачі.

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

call pvmfrecv (tid, msgtag, bufid)

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

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

Аналогом блокуючої функції є функція call pvmfnrecv (tid, msgtag, bufid).

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

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

call pvmfprobe (tid, msgtag, bufid)

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

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

call pvmfprecv (tid, msgtag, xp, cnt, type, rtid, rtag, rcnt, info).

Цю функцію можна використовувати для прийому повідомлень, в яких містяться однотипні дані. Виклик цієї функції ініціює процес очікування повідомлення, поміченого тегом msgtag від процесу з ідентифікатором tid. За надходження повідомлення pvm_precv розпаковує дані загальним обсягом len  (size of data type) в буфер buf.

Типи даних в FORTRAN-програмах такі ж, як це дано в описі функції pvmfpack.

 

         10.4.5 Установка PVM

Встановлення системи PVM на комп'ютері, що працює під управлінням операційної системи Linux достатньо проста і не вимагає тривалих налаштувань. Cистема PVM розповсюджується безкоштовно і у вихідних кодах. Для установки PVM у вашій системі необхідно створити каталог, де буде розташовуватися система PVM. Будемо вважати, що ми встановлюємо PVM в каталог /pvm3. У цей каталог необхідно розпакувати архів з вихідними кодами системи.

tar zxvf pvm3.3.4.tgz

Перед складанням і запуском PVM ви повинні встановити змінну оточення $PVM_ROOT, вказавши в ній повний шлях до каталогу, в якому зберігається система. Якщо слід використовувати в якості командної оболонки csh, вам необхідно додати наступний рядок у файл. Cshrc:

setenv PVM_ROOT = /pvm3

Якщо ж ви використовуєте оболонки, які використовують Profile, наприклад sh або ksh, або bash, яка використовує Bashrc, тоді треба додати до відповідного файлу таку команду:

export PVM_ROOT =/pvm3

Так само ви повинні визначити інші змінні оточення, необхідні для функціонування PVM, додавши після команди визначенняPVM_ROOT вміст відповідних командн в оболонці файлів: pvm3/lib/cshrc.stub,

pvm3/lib/kshrc.stub або pvm3/lib/bashrc.stub.

За замовчуванням PVM використовує протокол rsh для спілкування з іншими комп'ютерами кластера. Якщо ви хочете rsh замінити на ssh, потрібно змінити файл /pvm3/conf/LINUX.def, прописавши в змінної ARCHCFLAGS параметр RSHCOMMAND, визначивши для нього повний шлях до команди ssh (наприклад /usr/bin/ssh). Наприклад /pvm3/conf/LINUX.def виглядає так:

# ARCHCFLAGS =-DSYSVSIGNAL-DNOWAIT3-DRSHCOMMAND = \ "/ usr

/bin/ssh\-DNEEDENDIAN-DFDSETNOTSTRUCT-DHASERRORVARS\-DCTIMEISTIMET-DSYSERRISCONST-DNOTMPNAM 
ARCHDLIB =

ARCHDOBJ =

ARCHLIB =

HASRANLIB = t

AR = ar

PVM_ARCH = LINUX

MAKE = make

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

Для побудови та встановлення PVM, перебуваючи в каталзі /pvm3, виконайте команду make. По закінченні її роботи система PVM готова до запуску. Слід зазначити, що для зменшення проблем, пов'язаних з настройкою PVM на вузлах кластеру, на всіх машинах кластеру PVM слід встановлювати в один і той же каталог.

 

         10.4.6 Адміністрування PVM

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

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

Для запуску віртуальної машини необхідно виконати команду pvm. Ця команда запускає консоль паралельної віртуальної машини PVM. Команда pvm перед запуском консолі перевіряє наявність у системі демона pvmd, запущеного від імені користувача, який виконує команду pvm. Таким чином в системі можуть бути присутні кілька демонів pvmd (кілька паралельних віртуальних машин), що належать різним користувачам. З іншого боку два користувачі, що підключилися до консолі кластера під одним ім'ям, будуть користуватися однією і тією ж віртуальною машиною. Доступ користувачів до консолі під різними іменами забезпечити безпеку для виконуваних програм. Оскільки запущені програми будуть виконуватися під різними віртуальними машинами, то користувачі не зможуть перешкодити один одному, наприклад зняти з виконання чуже завдання. З іншого боку, робота всіх користувачів під одним login'ом забезпечить простоту адміністрування запущених завдань. У цьому випадку користувач може бути позбавлений необхідності самостійно конфігурувати склад кластеру. Проте це додасть ризик неправомірного впливу користувачем на чужі завдання. Користувач може, наприклад, зупинити віртуальну машину командою halt, знявши тим самим з виконання всі запущені в рамках цієї віртуальної машини завдання. Яким чином забезпечити користувачам доступ до консолі кластеру ви повинні вирішити самостійно.

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

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

pvm> add node1

pvm> add 192.168.1.3

pvm> add node3.cluster.mydomain.org

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

pvm> add node1

add node1

user1 @ node1's password:

1 successful

HOST DTID

node1 80000

pvm>

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

pvm> conf

conf

2 hosts, 1 data format

HOST DTID ARCH SPEED DSIG

server 40000 LINUX 1000 0x00408841

node1 80000 LINUX 1000 0x00408841

pvm>

Для кожної машини списку дана інформація, що включає в себе ім'я машини (коротке або повне доменне ім'я, або ip-адреса)HOST, ідентифікатор завдання DTID демона PVM, назву архітектури підключення машини ARCH, якесь число SPEED, що відображає швидкісні характеристики машини та ідентифікатор самої віртуальної машини DSIG, яка буде розрізнена для віртуальних машин, запущених різними користувачами.

Замість того, щоб вручну додавати кожен вузол кластеру у віртуальну машину, можна при першому запуску pvm вказати в якості першого параметра команди ім'я текстового файлу, в якому перераховані імена (короткі або повні доменні) або ip-адреси вузлів кластеру. Правило складання такого файлу просте: один вузол - один рядок. У разі використання списку вузлів, PVM самостійно виконає підключення перерахованих у файлі машин. Ймовірно пріавильним і зручним буде забезпечити безпарольний доступ по протоколу SSH до вузлів кластеру з консолі кластера і виконання команди "pvm hostlist" з startup-файлу користувача (наприклад. Bashrc).

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

pvm> spawn timing

spawn timing

1 successful

t40002

pvm>

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

pvm> spawn -> hello

spawn -> hello

[1]

1 successful

t40004

[1: t40005] Message from slave process

[1: t40004] i'm t40004

[1: t40004] from t40005: hello, world from yis

[1: t40005] EOF

[1: t40004] EOF

[1] finished

pvm>

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

pvm> ps-a

ps-a

HOST TID FLAG 0x COMMAND

server 40002 6 / c, f timing

node1 80002 6 / c, f timing_slave

pvm>

У прикладі ми бачимо, що запущене нами завдання timing залишилася працювати на консолі кластеру "server" і породила насайті "node1" дочірній процес timing_slave.

Для зняття процесу з рахунку можна скористатися командою kill, параметрами якої є ідентифікатори завдань (TID) процесів, які підлягають видаленню з системи. Ідентифікатори завдань можна подивитися за допомогою раніше описаної команди ps. Так, для видалення з системи процесів "timing" і "timing_slave" з попереднього прикладу, команда ps буде виглядати наступним чином:

pvm> kill 40002 80002

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

pvm> reset

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

pvm> quit

Повторний вхід в консоль працючої віртуальної машини здійснюється запуском команди pvm.

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

pvm> halt

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

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

 

         10.5 Інтерфейс передачі повідомлень (MPI)

 

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

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

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

В даний час різними колективами розробників написано кілька програмних пакетів, що задовольняють специфікації MPI, зокрема: MPICH, LAM, HPVM, OpenMPI і так далі. У двох словах охарактеризуємо найбільш поширені з цих пакетів. Якщо говорити про LAM, то основна перевага цього пакету - багаті налагодження можливостей. Трасування звернень до MPI та аналіз стану паралельної програми після аварійного завершення роблять процес налагодження менш важким і більш продуктивним. З іншого боку, пакет MPICH більш мобільний, слідуючи простим інструкціям можна перенести MPI на нову платформу (наприклад з Linux на Windows або навпаки). Для цього потрібно написати лише кілька драйверів нижнього рівня.Установка бібліотеки MPICH проходить трохи важче, ніж установка LAM MPI, оскільки доводиться задавати набагато більше число параметрів, причому призначення деяких з них відомо тільки розробникам.

MPI - це добре стандартизований механізм для побудови програм по моделі обміну повідомленнями. Існують стандартні "прив'язки" MPI до мов С/С + +, Fortran 77/90. Є і безкоштовні і комерційні реалізації майже для всіх суперкомп'ютерних платформ, а також для High Performance кластерних систем, побудованих на вузлах з ОС Unix, Linux та Windows. В даний час MPI - найбільш широко використовується і динамічно розвивається інтерфейс зі свого класу. У новій версії стандарту 2.0 описано велику кількість нових цікавих механізмів і процедур для організації функціонування паралельних програм: динамічне управління процесами, односторонні комунікації (Put/Get), паралельні I/O. Але на жаль, поки немає повних готових реалізацій цієї версії стандарту, хоча частина з нововведень уже активно використовується.

 

10.5.1 Встановлення системи MPI

Встановлення системи MPI на комп'ютерах кластера аналогічна установці PVM, в тому сенсі, що установка зводиться до компіляції системи з вихідних кодів. З моєї точки зору найбільш простими у використанні є пакети MPICH і OpenMPI, які на відміну від LAM/MPI не в змозі запускати додаткові демони і вимагають мінімальних налаштувань. Моя особиста рекомендація - OpenMPI. Цей пакет в даний час активно розвивається і має хорошу інтеграцію з системами керування чергами і grid-системами. Крім того пакет MPICH перестав розвиватися з 2005 року.

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

Першим кроком у встановленні MPI є одержання вихідних кодів пакета. Отримавши архів mpich.tar.gz, lam-7.1.3.tar.gz абоopenmpi-1.3.3.tar.bz2, ви повинні розпакувати його в будь-якому каталозі вашої файлової системи і запустити скрипт конфігурації configure:

MPICH

./Configure-with-arch = LINUX-with-device = ch_p4-rsh =/usr/bin/ssh \

--prefix = /usr/local/mpich-1.2.6/ch_p4

LAM / MPIH

./Configure --prefix =/usr - with-rsh = "/usr/bin/ssh-x"

OpenMPI

./Configure - prefix =/usr

У параметрах скрипта configure визначається тип архітектури машини (тільки для MPICH), на якій буде встановлено пакет MPI (в даному випадку LINUX) і шлях до каталогу, в який пакет буде встановлений (/usr/local/mpich-1.2.6/ch_p4 або /usr).Слід зазначити, що на всіх вузлах кластера необхідно встановити MPI в один і той же каталог. Будучи запущеним, скрипт configure обстежує операційну систему і підготує пакет MPI до компіляції з урахуванням її особливостей.

За замовчуванням MPI використовує rsh як засіб міжвузлових комунікацій. Як вже говорилося раніше, з деяких причин переважніше замінити rsh на більш комфортний в адмініструванні ssh, забезпечивши при цьому безпарольний доступ до вузлів кластера з консольної машини. Для цього при запуску скрипта configure використовуємо параметр -rsh = /usr /bin/ssh для MPICH і - with-rsh = "/usr/bin/ssh-x" для LAM/MPI. Якщо програма ssh перебуває у вашій системі в іншому місці, то значення параметра-rsh або - with-rsh повинно бути відповідним чином змінено.

Як можна помітити, параметр - prefix, що визначає каталог, куди буде встановлений пакет, вказує на LAM/MPI системну область, а для MPICH на окремий каталог. Зроблено це тому, що пакет MPICH з якоїсь причини не підтримує команду деінсталяції "make uninstall". У випадку, коли вам з якоїсь причини треба буде видалити з системи пакет MPICH, зробити це буде набагато простіше, коли він знаходиться в якомусь одному своєму каталозі, замість того, щоб довго й нудно вичищати системну область.

 

10.5.2 Конфігурація кластеру MPICH

На відміну від PVM опис кластеру виконується не командами системи, а за допомогою редагування відповідного конфігураційного файлу. Для Linux-системи це файл /usr/local/mpich-1.2.6/ch_p4/share/machines.LINUX. Цей файл містить просте перерахування комп'ютерів, що входять у кластер і може виглядати наступним чином:

server

node1

node2.mydomain.com

192.168.1.33

node4: 2

Тобто, може використовуватися або коротке ім'я вузла, або доменне ім'я вузла, або його ip-адреса. Правило: один вузол - один рядок. В описі вузла "node4" у прикладі був використаний модифікатор ": 2". Це означає, що в якості четвертого вузла використовується двопроцесорна (SMP) машина.

Файл machines.LINUX повинен бути однаковим на всіх вузлах кластеру. Для перевірки працездатності MPI необхідно запустити скрипт /   usr/local/mpich-1.2.6/ch_p4/sbin/testmachines:

/usr/local/mpich-1.2.6/ch_p4/sbin/testmachines-v LINUX

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

[User @ server sbin] #. / Tstmachines-v LINUX

Trying true on server ...

Trying ls on server ...

Trying user program on server ...

Trying true on node1 ...

Trying ls on node1 ...

Trying user program on node1 ...

Trying true on node2 ...

Trying ls on node2 ...

Trying user program on node2 ...

[User @ server sbin] #

Скрипт tstmachines, намагаючись перевірити доступність вузла кластеру, послідовно намагається запустити на ньомупрограми /bin/true, /bin/ls й певну налаштовувану програму /usr/local/mpich1.2.6/ch_p4/sbin/tstfoo. Оригінальний текст програми tstfoo на мові C виглядає так:

main () (return 0;)

 

         10.5.3 Конфігурація кластеру LAM/MPI

Абревіатура LAM в назві пакету розшифровується як "Local Area Machine", що вказує на початкову орієнтацію пакету у використання його для кластера, побудованого з мережі робочих станцій.

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

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

# My boot schema

node1.cluster.example.com

192.168.1.123

node3.cluster.example.com cpu = 2

Перший рядок - це коментар. Решта рядки - це перерахування машин, що входять у кластер. Перша машина задана доменним ім'ям. Посилання на другу машину задана її ip-адресою. Третя машина також описана доменним ім'ям з параметром "cpu = 2". Параметр цей означає, що машина node3 є двопроцесорним SMP комп'ютером.

Для завантаження LAM використовується команда lamboot, запуск которрой виглядає наступним чином:

[User @ server yuri] $ lamboot-v-ssi boot rsh. / Hostfile

LAM 7.0.6/MPI 2 C + + / ROMIO - Indiana University

n-1 <29699> ssi: boot: base: linear: booting n0 node1.cluster.example.com)

n-1 <29699> ssi: boot: base: linear: booting n1 (192.168.1.123)

n-1 <29699> ssi: boot: base: linear: booting n2 (node1.cluster.example.com)

n-1 <29699> ssi: boot: base: linear: finished

Для успішного запуску LAM повинні бути виконані наступні умови:

1)                Всі машини, описані в hostfile повинні бути включені і доступні по мережі.

2)                Користувач повинен мати безпарольний доступ до цих машин по протоколу SSH.

3)                Вихідні коди системи LAM на цих машинах повинні знаходиться в каталогах, зазначених у змінній оточення PATH.

4)                Якщо машина описана доменним ім'ям, то вона повинна бути прописана в системі DNS або в системному файліhosts.

Переглянути поточну конфігурацію кластеру можна за допомогою команди lamnodes:

[User @ server yuri] # lamnodes

n0 node1.cluster.example.com: 1

n1 192.168.1.123:1

n2 node3.cluster.example.com: 2

Зупинити роботи LAM-всесвіту можна командою lamhalt

 

10.5.4 Конфігурація кластеру OpenMP

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

Server

node1

node2.mydomain.com

192.168.1.33

Тобто, може використовуватися або коротке ім'я вузла, або доменне ім'я вузла, або його ip-адреса. Правило: одні вузол -один рядок.

Для перевірки працездатності OpenMPI необхідно на паралельне виконання будь-яку просту програму, наприклад hostname, яка покаже ім'я хоста, на якому вона запущена. Робиться це наступного командою:

mpirun-hostfile mpi.host-np 4 hostname

Команда mpirun має три параметри. Перший (-hostfile) вказує на файл, що містить список вузлів кластеру. Другий (-np)задає кількість процесорів (вузлів кластера), на яких ця програма буде запущена. І третій параметр - власне сама програма, яка буде запущена на паралельне виконання.

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

[User1 @ server sbin] # mpirun-hostfile mpi.host-np 4 hostname

node1.cluster.org

node2.cluster.org

node3.cluster.org

node4.cluster.org

[User 1 @ server sbin] #

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

 

         10.5.5 Компіляція і виконання

Процес компіляції та виконання паралельних програм, написаних з використанням MPI, приблизно однаковий у MPICH, LAM/MPI та OpenMPI. Обидва пакети містять у собі спеціалізовані скрипти (wrappers) полегшують виклик компіляторів. Для мови FORTRAN такий скрипт називається mpif77. Компіляція вихідного тексту програми, написаної на FORTRAN виконується наступним чином:

mpif77 myprog.f-o myprog

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

Наступний етап роботи з кластером - запуск паралельних програм на виконання. В обох версіях MPI, які ми розглядаємо, запуск програми відбувається за допомогою команди mpirun:

MPICH, OpenMPI

mpirun-np 4-machinefile ~/machines/tmp/prog1/myprog

LAM/MPI

mpirun-np 4 /tmp/prog1/myprog

Параметр-np задає кількість процесорів кластеру, на яких буде запущена програма. Для MPICH використовується додатковий параметр-machinefile, який вказує на файл (~ /machines), що містить список машин кластера. Природно, тут представлено найпростіші варіанти запуску. Команда mpirun має набагато більше параметрів, що дозволяють оператору кластеру довільно формувати завдання на рахунок.

 

         10.5.6 Загальна організація MPI

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

1)        Функції ініціалізації та закриття MPI процесів.

2)        Функції, що реалізують комунікаційні операції типу точка-точка.

3)        Функції, що реалізують колективні операції.

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

5)        Функції для роботи зі структурами даних.

6)        Функції формування топології процесів.

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

1) Локальна функція - виконується всередині що викликає процес. Її завершення не вимагає комунікацій.

2) Нелокальна функція - для її завершення потрібно виконання MPI-процедури іншим процесом.

3) Глобальна функція - процедуру повинні виконувати всі процеси групи. Недотримання цієї умови може приводити до зависання завдання.

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

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

У мові FORTRAN більшість MPI-процедур є підпрограми (викликаються за допомогою оператора CALL), а код помилки повертають через додатковий останній параметр процедури. Кілька процедур, оформлених у вигляді функцій, код помилки не повертають. Не потрібно суворого дотримання регістру символів в іменах підпрограм і іменованих констант. Масиви індексуються з 1. Нижче наведено відповідність наперед визначених в MPI типів стандартним типам мови FORTRAN.

Тип MPI                      Тип мови FORTRAN

MPI_INTEGER                  INTEGER

MPI_REAL                     REAL

MPI_DOUBLE_PRECISION         DOUBLE PRECISION

MPI_COMPLEX                  COMPLEX

MPI_LOGICAL                 LOGICAL

MPI_CHARACTER                    CHARACTER (1)

MPI_BYTE

MPI_PACKED

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


законы диалектики

Основные законы диалектики.

1)Закон единства и борьбы противоположностей.

Этот закон является «ядром» диалектики, т.к. определяет источник развития, отвечает на вопрос, почему оно происходит.

Содержание закона: источник движения и развития мира находится в нем самом, в порождаемых им противоречиях.

Противоречие – это взаимодействие противоположных сторон, свойств и тенденций в составе той или иной системы или между системами. Диалектическое противоречие есть только там, где...

Русский язык и культура речи

перейти к оглавлению

1. ЭЛЕМЕНТЫ И УРОВНИ ЯЗЫКА

Характеризуя язык как систему, необходимо определить, из каких элементов он состоит. В большинстве языков мира выделяются следующие единицы: фонема (звук), морфема, слово, словосочетание и предложение. Единицы языка неоднородны по своему строению: простые (фонемы) и сложные (словосочетания, предложения). При этом более сложные единицы всегда состоят из более простых.

Самая простая единица языка – это фонема, неделимая и сама по себе...

Идеология

1.Идеология как социальный феномен, её сущность. Содержание идеологииСоциально-исторической системой представлений о мире стала идеология как система рационально- логического обоснования поведения людей, их ценностей, норм взаимоотношений, целей и т.д. Идеология как явление во многом сходна с религией и с наукой. От науки она восприняла доказательность и логичность своих постулатов, но, в отличие от науки, идеология призвана давать оценку явлениям действительности (что хорошо, что...

Математические формулы. Шпаргалка для ЕГЭ с математики

Формулы сокращенного умножения

(а+b)2 = a2 + 2ab + b2

(а-b)2 = a2 – 2ab + b2

a2 – b2 = (a-b)(a+b)

a3 – b3 = (a-b)( a2 + ab + b2)

a3 + b3 = (a+b)( a2 – ab + b2)

(a + b)3 = a3 + 3a2b+ 3ab2+ b3

(a – b)3 = a3 – 3a2b+ 3ab2- b3

Свойства степеней

a0 = 1 (a≠0)

am/n = (a≥0, n ε N, m ε N)

a- r = 1/ a r (a>0, r ε Q)

m...