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

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

3 модуль. ПП -mike

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

 

10.1 Будова кластера

 

         В загальному розгортання кластеру як такого - завдання актуальне та доволі не складне. Причому, для цього підійде будь-який дистрибутив. Який саме з дистрибутивів Linux ставити в якості базової ОС - не має значення. Ubuntu, Mandriva, Alt Linux, Red Hat, SuSE ... Вибір залежить тільки від уподобань користувача.

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

1.                Встановити операційну систему на комп'ютер, який буде виступати в ролі консолі кластеру. Тобто на цьому комп'ютері будуть компілюватися і запускатися паралельні програми. Іншими словами, за цим комп'ютером буде сидіти людина, запускати програми і дивитися, що вийшло.

2.                Після інсталяції базової ОС на консолі кластера, якщо це не зроблено в процесі первісної установки, необхідно буде встановити необхідні компілятори (фортран, С) і всі необхідні бібліотеки, desktop environment (GNOME або KDE), текстові редактори і т.д., тобто перетворити цей комп'ютер в робочу станцію розробника.

3. Встановити з репозитарію або з вихідного пакет MPICH або OpenMPI.

4. Описати в /etc/hosts майбутні вузли вашого кластеру, в тому числі і консоль кластеру.

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

6. Встановити на консолі кластеру ssh-клієнт (обов'язково) та ssh-сервер (опціонально, якщо буде надаватися доступ до консолі кластеру по мережі).

7. На всіх вузлах кластера встановити операційну систему, бібліотеки, необхідні для виконання користувальницьких паралельних програм, встановити MPICH, NFS-client, ssh-server. Вузли кластера в цілях економії ресурсів повинні навантажуватися в runlevel 3, так що ставити туди GNOME або KDE не треба. Максимум - поставити ряд бібліотек, якщо вони потрібні для користувача.

8. Описати в /etc/hosts всіх вузлів кластера майбутні вузли вашого кластеру, в тому числі і консоль кластеру.

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

10. На всіх вузлах кластера забезпечити безпарольний доступу по ssh для консолі кластеру.

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

Таким чином і в консолі кластеру та в його вузлах необхідно мати два мережевих інтерфейси (дві мережеві карти), відповідно, потрібно два набори світчів, не пов'язаних один з одним, і два набори мережевих реквізитів для цих інтерфейсів. Тобто, NFS працює, наприклад, в мережі 192.168.1.0/24, а обмін даними відбувається в мережі 192.168.2.0/24. І відповідно, у файлах /etc/exports і /etc/fstab повинні будуть бути прописані адреси з першої мережі, а у файлах /etc/hosts і в файліmachines.LINUX, що описують кластер - адреси з другої.

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

1. Наявна різницева сітка розміру R, обчислення на якій при використанні звичайного комп'ютера займають час T. Час T - критичний параметр. Нам хочеться істотно зменшити час обчислень, маючи R як константу.

2. Наявна різницева сітка розміру R, обчислення на якій при використанні звичайного комп'ютера займають час T. Час T - не критично. Нас цікавить збільшення розміру сітки понад наявною в одному комп'ютері пам'яті для більш детального рахунку, можливого отримання більш тонких ефектів і т.п.

         Всі обчислення на різницевій сітці мають один спільний і важливий для нас параметр: час однієї ітерації. У разі використання кластеру цей час складається з двох частин: час рахунку на сітці Titer і час обміну даними між вузлами Texch. Titer залежить тільки від потужності процесора. А ось Texch залежить вже від розміру різницевої сітки, кількості вузлів кластеру та пропускної здатності мережі. Наведу остаточний результат для випадку двухгігабітної мережі, розміру різницевої сітки 64 гігабіти і часі однієї ітерації 100 сек.

 

Рисунок 10.1 – Часова характеристика обрахунку даних

 

         На графіку вісь ординат - тимчасова характеристика, вісь абсцис - кількість вузлів кластеру.

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

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

 

Рисунок 10.2 – Часова характеристика обрахунку даних

 

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

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

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

 

10.2 Організація мережі обчислювального кластеру

 

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

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

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

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

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

 

         10.2.1 Мережеві карти

В якості мережевих адаптерів можна використовувати будь-які наявні в продажу карти, що підтримують роботу в стандартах 100BaseTx і GigabitEthernet. Що стосується списку переваг, то можна порекомендувати в першу чергу 3Com. Серед інших варіантів можна назвати Compex, Intel, Macronix, інші карти, підтримувані драйвером tulip, наприклад карти на чіпсетах DC21xxx. Особливо популярними при побудові кластерів явяляются плати на базі мікросхем Intel 21142/21143. Популярність цих карт викликана існуючим механізном високої продуктивності, в той час як їх ціна в порівнянні з конкуруючими пропозиціями зазвичай досить невелика. Що стосується мережевих карт фірми 3Com, то вони мають деякі переваги, помітно впливають на продуктивність мережевих комунікацій. Наведемо лише кілька прикладів можливостей апаратного забезпечення карт 3Com.

Розвантаження процесора при обчисленні контрольних сум TCP/UDP/IP. Звільняє центральний процесор від інтенсивних обчислень контрольних сум, виконуючи їх в самій мережевій платі. Тим самим підвищується продуктивність системи і час життя процесора.

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

Режим Bus mastering DMA: забезпечує більш ефективний обмін даними для зниження завантаження центрального процесора.

 

         10.2.2 Комутатори

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

         Комутатори та інші елементи мережевої структури використовуються для забезпечення комунікацій між процесорами, для підтримки паралельного програмування і різних функцій управління. Для паралельного програмування організації взаємодії між процесами (Inter Process Communication, IPC) широко використовується комутатор Myrinet-2000 - дуже швидкий, добре масштабований широкосмуговий пристрій.     

        

         10.2.3 Мережеве забезпечення кластеру.

Як вже говорилося, вузли кластеру можна зв'язати звичайним способом, використовуючи Ethernet-адаптери. З'єднання машин кластеру може виглядати так, як це показано на рисунку 10.3.

Рисунок 10.3 – З’єднання машин кластера

 

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

Інтерфейс користувача рівня для такого "злиття" каналів складається з двох програм: 'ifconfig' і 'ifenslave'. Перший мережевий інтерфейс конфігурується як зазвичай командою 'ifconfig'. Програма 'ifenslave' копіює установки першого інтерфейсу на всі інші додаткові інтерфейси. Цією ж командою можна при бажанні будь-які інтерфейси сконфігурувати в режимі Rx-only. 
         Для і програм, що виконуються на кластері, метод абсолютно прозорий. Єдине вплив, який він надає - збільшення швидкодії.

Застосування методу має деякі обмеження: всі приєднані машини повинні мати однаковий набір bonded networks, тобто не можна в одній машині використовувати 2х100BaseTx, а в іншій 10Base і 100BaseTx. Застосування методу складається з двох частин, необхідні зміни Кернел для підтримки channel bonding, і програма ifenslave.


 

         10.2.4 Мережева файлова система

         Однією з особливостей запуску MPI-програм є необхідність наявності копій програми на всіх вузлах кластера, на яких вона виконується. Наприклад, якщопрограма myprog розташована в каталозі /home/mpiuser/program1, то на всіх вузлах кластера повинен бути присутнім цей каталог і в нього повинна бути поміщена програма.

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

Для позбавлення від подібних проблем використовуються мережеві файлові системи. Існує велика кількість реалізацій таких систем, як платних, так і поширюваних під ліцензією GPL. Розглянема мережеву файлову систему NFS, наявну в будь-якому Linux-дистрибутиві загального призначення. Файлова система NFS - це аналог того, що й продукт Майкрософт відомий під назвою windows share.

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

 

10.2.5 Конфігурація сервера

Для забезпечення мережевого доступу вузлів кластеру до розшарених на сервері кластеру ресурсів необхідно спочатку вирішити підключення nfs-клієнтам до nfs-сервера. Далі будемо припускати, що вузли кластера мають ip-адреси в діапазоні 192.168.1.2-192.168.1.254. Консоль кластеру, до каталогів файлової системи до якої ми будемо підключатися через NFS, має ip-адреса 192.168.1.1. Для дозволу мережевого доступу до NFS з цих адрес у файлі /etc/hosts.allow прописуємо наступну рядок:

portmap: 192.168.1.1

Крапка в кінці рядка обов'язкова. Далі слід визначити до якого каталогу ми дозволяємо мережевий доступ. Тобто, якому каталогу давати доступ. Приміром,необхідно забезпечити у вузлах кластеру доступ до каталогу /home/mpiuser/data-and-progs. Для цього у файлі /etc/exports прописуємо рядок:

/Home/mpiuser/data-and-progs 192.168.1.0/255.255.255.0 (rw,no_root_squash)
         На цьому налаштування серверної частини закінчено. Щоб зміни вступили в силу необхідно перезапустити службу NFS за допомогою команди "service portmap restart".

 

10.2.6 Конфігурація клієнтів

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

Для підключення будь-якої файлової системи (розділу диска, мережевого ресурсу) використовується команда mount, якщо підключення відбувається вручну, або запис у файлі /etc/fstab, якщо підключення відбувається в момент завантаження системи. Нас буде цікавити останній випадок.

Для забезпечення запуску mpi-програм нам потрібно, щоб вміст каталогу /home/mpiuser/data-and-progs на вузлах кластеру збігався з вмістом цього ж каталогу на консолі кластеру. Для цього необхідно в домашньому каталозі користувача mpiuser (/home/mpiuser) створити порожній каталог data-and-progs. Після чого прописати у файлі /etc/fstab такий рядок:

192.168.1.1: /home/mpiuser/data-and-progs/home/mpiuser/data-and-progs nfs rw 0 0

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

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

 

         10.2.7 SSH, беспарольный доступ

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

Алгоритм забезпечення безпарольного доступу наступний: 
         1. Логін до консолі кластера: ssh user1@server 
         2. Переходимо в каталог ssh: cd ~ /. Ssh 
         3. Генеруємо rsa-ключі: ssh-keygen-t rsa 
         4. На питання задати ім'я файлу тиснемо Enter - залишається ім'я за замовчуванням id_rsa. 
         5. На прохання поставити пароль тиснемо Enter два рази (другий раз для перевірки). 
         6. Копіюємо публічний ключ на вузол кластеру: scp id_rsa.pub user1@node1: ~ /.Ssh

         7. Логіном до вузла node1: ssh user1@node1 
         8. Переходимо в каталог ssh: cd ~ /.Ssh 
         9. Копіюємо публічний ключ: cat id_rsa.pub>> authorized_keys2 
         10. Відключаємося від вузла node1 
         11. Повторюємо пункти 6-10 для інших вузлів кластера (node2 ... nodeN)

Після проведення описаної процедури користувач "user1" зможе підключатися до вузлів кластеру з консолі кластера не вводячи свій пароль. Слід зазначити, таким чином забезпечується безпарольний доступ лише для одного користувача і лише в одному напрямку: консоль кластеру -> вузли кластеру. І тільки для випадку, коли user1 підключається до вузлів кластеру під своїм ім'ям.

 

         10.3 Розпаралелювання програм

 

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

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

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

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

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

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

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

 

         10.3.1 Варіанти декомпозиції

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

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

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

 

         10.3.2 Тривіальна декомпозиція

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

Рисунок 10.4 – Приклад тривіальної декомпозиції

 

         10.3.3 Функціональна декомпозиція

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

Припустимо наше завдання зводиться до застосування якогось функціонального оператора до великого масиву даних: S = F (a ). Припустимо також, що виконання функції F над одним елементом масиву займає досить великий час і нам хотілося б цей час скоротити. У цьому випадку ми можемо спробувати уявити вихідну функцію як композицію декількох фунуцій: S (a ) = I (H (R (a ). Зробивши декомпозицію ми отримаємо систему послідовних завдань:

x = r (a );

y = h (x);

= i (y);

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

 

 

Рисунок 10.5 – Приклад функціональної декомпозиції

 

У цього методу декомпозиції є пара особливостей, про які треба пам'ятати. 
Перша особливість полягає в тому, що вихід кластеру на максимальну ефективність відбувається не відразу після запуску завдання, а поступово, у міру того, як відбувається часткова обробка першого елемента масиву. Другий і третій процесори в нашому прикладі, які відповідають за виконання функцій g(x) і f(y), будуть простоювати до тих пір, поки не закінчиться виконання функції h(a[1]) на першому процесорі. Третій процесор буде простоювати до закінчення виконання функції g(a[1]). За аналогічним сценарієм, тільки в дзеркальному відображенні, відбувається закінчення роботи.

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

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

 

 

10.3.4 Декомпозиція даних

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

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

 

         10.3.5 Regular Domain Decomposition

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

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

 

Рисунок 10.6 – Регулярна декомпозиція вихідної решітки

 

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

 

         10.3.6 Сітка процесів

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

 

 

Рисунок 10.7 – Глобальний набір даних декомпозиції

 

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

 

10.3.7 Зміна елементів даних

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

 

10.3.8 Область перекриття

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

 

 

Рисунок 10.8 – Область процесу перекриття

 

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

 

10.3.9 Граничний обмін

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

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

 

 

Рисунок 10.9 – Процеси граничного обміну

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

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

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

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

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

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

3) Виконуємо обробку даних.

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

 

10.3.10 Деталізація

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

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

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

          10.4 Паралельна віртуальна машина (PVM)

 

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

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

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

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

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

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

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

        

10.4.1 Взаємодія завдань у PVM

У системі PVM кожне завдання, запущене на деякому процесорі, ідентифікується цілим числом, яке називається ідентифікатором завдання (TID) і за змістом схоже на ідентифікатор процесу в операційній системі Unix. Система PVM автоматично підтримує унікальність таких ідентифікаторів: копії одного виконуваного файлу, запущеного паралельно на N процесорах PVM, створюють N завдань з різними TID.

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

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

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

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

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

 

         10.4.2 Управління завданнями

Управління завданнями в PVM здійснюється на основі деякого набору функцій. Існує два варіанти написання паралельних завдань для PVM. У першому варіанті весь виконуваний на всіх процесорах код пишеться як одне велике завдання. Відповідно на кожному процесорі запускається на виконання один і той же файл. Зазвичай на самому початку своєї роботи програма викликає функцію call pvmfmytid (tid), повертає значення ідентифікатора завдання tid> = 0, яким може визначатися вибір для виконання тієї чи іншої частини програми. Ця функція може викликатися більше одного разу.

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

call pvmfspawn (task, flag, where, ntask, tids, numt);

task - ім'я виконуваного файлу;

INTEGER flag - опції запуску;

where - вказує місце запуску;

INTEGER ntask - число запусщених копій програми;

INTEGER tids - масив значень tid для запущених завдань.

Ця функція запускає в PVM ntask копії виконуваного файлу з ім'ям "task" з однаковими аргументами командного рядка в масиві argv і повертає число запущених завдань numt а також послідовність ідентифікаторів для запущених завдань. Другий варіант написання паралельного завдання полягає в тому, що для кожного процесора пишуться свої власні завдання, що виконують різні дії, і створюється маленька програма, яка, використовуючи функцію pvm_spawn запускає всі інші завдання.

Виконуваний файл для функції pvm_spawn () повинен перебувати в строго визначеному каталозі. Під Unix завдання шукається в каталогах $PVM_ROOT/bin/$PVM_ARCH/ і $HOME/pvm3/bin/ $PVM_ARCH. Задавати ім'я каталогу в параметрі "task" неприпустимо.

Але це не єдиний спосіб. В іншому варіанті виконуваний файл шукається (і запускається) не тільки на тому комп'ютері, на якому працює викликанеpvm_spawn () завдання, але в залежності від параметрів flag і where, на будь-якому вхідному до складу PVM. Наприклад, якщо flag == 0, то PVM сам вибирає, на якій з машин запускати нові завдання (головне, щоб додаток був скомпільовано на цих машинах); а якщо flag & PvmMppFront> 0, то місцем запуску буде обранийнайшвидший комп'ютер.

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

FORTRANe flag може бути сумою таких величин:

PVMDEFAULT = 0 - PVM може вибрати будь-яку машину для старту завдання,

PVMHOST = 1 - параметр where визначає машину для запуску,

PVMARCH = 2 - параметр where визначає тип архітектури,

PVMDEBUG = 4 - процес стартує під відгадчиком,

PVMTRACE = 8 - процес генерує PVM trace data.

Параметр where описує на яких комп'ютерах кластера може бути запущене завдання. Параметр є простою строковою змінною, в яку записано ім'я списку комп'ютерів. Списки комп'ютерів знаходяться у конфігураційних файлах системи PVM і формуються на етапі її установки. Наприклад у випадку, коли у вашому кластері крім консольної машини присутній ще два комп'ютери: один класу P166 та іншой класу P4, ви можете визначити їх в системі під іменами "oldcomp" і "supercomp". І залежно від тих або інших умов, запускати свої завдання на якусь з машин кластеру.

І, нарешті, ще дві функції, пов'язані з управлінням завданнями:

call pvmfkill (tid, info)

call pvmfexit (info)

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

 

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

Здійснення повідомлень в PVM призначена для передачі даних між різними процесами і складається з трьох кроків. По-перше, буфер даних перед посиланямповинен бути ініціалізований першим з використанням функцій pvm_initsend () або pvm_mkbuf (). По-друге, дані, що пересилаються повинні бути упаковані в цей буфер. Для пакування використовується деяка кількість комбінацій викликів функції pvm_pk * (). У FORTRAN упаковка даних проводиться підпрограмою pvmfpack (). Третій крок полягає у пересиланні даних адресатам. Для цієї мети в залежності від списку адресатів використовується виклик функції pvm_send (), в параметрах яких вказується конкретний процес-приймач, або функції pvm_mcast (), що використовується для всеспрямованої передачі.

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

1) Для прийому будь-яких повідомлень.

2) Для прийому будь-яких повідомлень від певного джерела.

3) Для прийому будь-яких повідомлень з певним message tag.

4) Для прийому будь-яких повідомлень з певним message tag з певного джерела.

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

Буфер повідомлення call pvmfinitsend (encoding, bufid).

Якщо користувач використовує тільки один буфер повідомлення, то єдина необхідна для роботи з буфером функція - це pvm_initsend (). Ця функція викликається безпосередньо перед упаковкою нової порції пересилаючих даних в буфер повідомлення. Функція pvm_initsend звільняє буфер і створює новий для пакування в нього даних. Схема кодування упаковується в буфер даних і вказується завданням змінної encoding. Повернене в змінну bufid значення є ідентифікатором буфера.

Мінлива encoding може приймати такі значення:

1) 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 функцій, що утворюють мінімально повний набір, достатній для написання найпростіших програм.


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

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

(а+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...

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

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

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

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

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

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

Политология. Универсальная шпаргалка

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

1. Место политологии среди гуманитарных наук

Политология развивается в тесном взаимодействии с другими гуманитарными науками. Их всех объединяет общий объект исследования — жизнь общества во всем многообразии ее конкретных проявлений.

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

1) Политология тесно связана с экономикой. Экономика дает соответствующее обоснование реализации экономических...

Идеология

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