Розподілені системи управління процесами

Размещено на http://www.allbest.ru

ТЕМА: РОЗПОДІЛЕНІ СИСТЕМИ УПРАВЛІННЯ ПРОЦЕСАМИ

1. ПОНЯТТЯ ПРОЦЕСУ. ВИЗНАЧЕННЯ ТА СТРУКТУРА

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

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

Прозорість паралельної роботи обходиться досить дорого. Так, наприклад, кожного разу при створенні процесу, операційна система повинна створювати абсолютно незалежний адресний простір. Виділення пам'яті вимагає ініціалізації сегменту пам'яті, наприклад, шляхом обнуління сегменту даних, копіювання відповідної програми в сегмент коду і розміщення її в стек тимчасових даних. Перемикання процесора між двома процесами - також досить дорога операція. Окрім збереження контексту процесора (у який входять значення регістрів, лічильник програми, вказівник на стек і т. п.) операційна система повинна також змінити регістри блоку управління пам'яттю (Memory Management Unit, MMU) і оголосити некоректним вміст кеша трансляції адрес, наприклад асоціативного буфера сторінок (Translation Lookaside Buffer, TLB). Крім того, якщо операційна система підтримує більше процесів, ніж може одночасно поміститися в оперативній пам'яті, перед дійсним перемиканням з одного процесу на іншій може виникнути потреба підкачки (swapping) процесів між оперативною пам'яттю і диском. розподілений клієнт сервер код агент

Процес складається з трьох сегментів: сегменту коду, сегменту ресурсів і сегменту виконання (рис. 3.1).

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

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

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

Рис. 3.1. Структура процесу

2. ПОТОКИ ВИКОНАННЯ. ВИЗНАЧЕННЯ ТА СТРУКТУРА

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

Будь-який потік складається з двох компонентів (рис. 3.2):

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

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

Рис. 3.2. Структура потоку виконання

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

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

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

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

3. СТАН ПРОЦЕСІВ ТА ПОТОКІВ ВИКОНАННЯ

У багатозадачній (багатопроцесорній) системі процес може знаходитися в одному з трьох основних станів:

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

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

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

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

Рис. 3.3. Типовий граф станів процесів

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

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

4. РЕАЛІЗАЦІЯ ПОТОКІВ ВИКОНАННЯ

Існує два підходи щодо реалізації потоків виконання: статичний і динамічний.

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

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

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

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

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

Приклад

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

Багатопотокова структура часто використовується при побудові великих програмних комплексів. Подібні програмні комплекси часто розробляються у вигляді наборів спільно працюючих програм, кожна з яких виконується окремим процесом. Цей підхід типовий для середовища UNIX. Кооперація між програмами реалізується у вигляді міжпроцессної взаємодії (через механізми Interproccessing Cooperation - IPC). Для UNIX-систем ці механізми зазвичай включають канали (поіменовані), черги повідомлень і спільно використовувані сегменти пам'яті. Основною оборотною стороною механізмів IPC є необхідність інтенсивного перемикання контекстів, продемонстрована трьома точками на рис.3.4.

Оскільки IPC вимагає втручання в ядро, процес зазвичай вимушений спочатку перемкнутися з призначеного для користувача режиму в режим ядра (точка S1). Це вимагає зміни карти пам'яті в блоці MMU, а також скидання буфера TLB. У ядрі відбувається перемикання контексту процесу (точка S2), після чого другий процес може бути активізований черговим перемиканням з режиму ядра в призначений для користувача режим (точка S3). Останнє перемикання знов потрубує зміни карти пам'яті в блоці MMU і скидання буфера TLB.



Рис. 3.4. Перемикання контекстів в результаті виклику IPC

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

Приклад

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

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

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

Багатопотокові клієнти

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

Традиційний спосіб приховати затримки зв'язку - ініціювавши взаємодію, відразу розпочати виконання іншої задачі.

Приклад

Типовим прикладом вживання цієї методики є web-браузери. У багатьох випадках web-документ, що міститься у файлі формату HTML, містить, окрім тексту, набір зображень, значків і тому подібне Для здобуття елементів web-документу браузер відкриває з'єднання TCP/IP, читає дані, що поступають, і перетворить їх в компоненти візуального представлення. Установка з'єднання, так само як і читання даних, є блокуючими операціями. При роботі з повільними комунікаціями відчуваються незручності, пов'язані з тим, що час, потрібний для завершення кожній з операцій, може бути досить тривалим. Web-браузер зазвичай спочатку отримує сторінку HTML-кода, а потім показує її. Для того, щоб по можливості приховати затримки зв'язку, деякі браузери починають показувати дані у міру їх отримання. Коли текст з механізмами прокрутки стає доступним користувачеві, браузер продовжує отримання останніх файлів, необхідних для правильного відображення сторінки, таких як картинки. Таким чином, для того, щоб побачити сторінку, користувач не повинен чекати отримання всіх її компонентів (рис. 3.5).



Рис. 3.5. Поетапне завантаження елементів сторінки Web-браузером

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

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

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

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

Багатопотокові сервери

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

Приклад

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

Рис. 3.6. Багатопотоковий сервер, організований за схемою диспетчер - робочий потік

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

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



Рис. 3.7. Багатопотоковий сервер, організований за схемою «команда»

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

Рис. 3.8. Багатопотоковий сервер, організований за схемою «конвейер»

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

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

Рис. 3.9. Алгоритм роботи кінцевого автомату

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

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

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

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

Таблиця 3.1

Три способи побудови сервера

Модель	Характеристики
Потоки виконання	Паралельність, блокуючі системні виклики
Однопоточний процес	Відсутність паралелізму, блокуючі системні виклики
Кінцевий автомат	Паралелізм, неблокуючі системні виклики

5. ОСОБЛИВОСТІ ПОБУДОВИ РОЗПОДІЛЕНОЇ СИСТЕМИ УПРАВЛІННЯ ПРОЦЕСАМИ НА ОСНОВІ МОДЕЛІ «КЛІЄНТ-СЕРВЕР»

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

Приклад

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

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

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

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

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

Приклад

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

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

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

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

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

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

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

Приклад

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

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

Приклад

Сервери, які обслуговують запити до FTP в Інтернеті, завжди працюють з портом 21. HTTP-серверам World Wide Web завжди призначається TCP-порт 80. Ці кінцеві точки визначені організацією призначення номерів Інтернету (Internet Assigned Numbers Authority - IANA). Маючи призначені кінцеві точки, клієнтові досить знати мережеву адресу тієї машини, на якій запущена служба. Для цієї мети використовуються служби іменування.

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

Приклад

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

Для визначення кінцевої точки клієнтом в процесі виконання розроблено рішення, яке реалізовано у розподіленому середовищі Distributed Computing Environment (DCE), - це створення спеціального демона, що запускається на кожній машині, на якій працюють сервери. Демон відстежує поточну кінцеву точку кожного з серверів, що реалізовуються на даній машині. Демон сам переглядає загальнодоступні кінцеві точки. При першому контакті з демоном клієнт запрошує кінцеву точку, після чого зв'язується з потрібним йому сервером.

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

Приклад

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

Рис. 3.11. Прив'язка клієнта до сервера з використанням демона в середовищі ОС і суперсервера в UNIX

Приклад

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

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

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

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

Приклад

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

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

Приклад

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

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

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

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

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

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

Сервери об'єктів

Сервер об'єктів (object server) - це сервер, орієнтований на підтримку розподілених об'єктів.

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

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



Рис. 3.12. Структура серверу об'єктів

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

Приклад

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

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

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

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

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

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

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

6. ПЕРЕНЕСЕННЯ КОДУ

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

6.1 Підходи до перенесення коду

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

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

Приклад

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

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

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

Приклад

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

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

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

Приклад

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

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

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

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

6.2 Моделі перенесення коду

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

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

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

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

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

Абсолютний мінімум для перенесення коду пропонує модель слабкої мобільності (weak mobility). Згідно цієї моделі допускається перенесення лише сегменту коду, можливо разом з деякими даними ініціалізації. Характерною рисою слабкої мобільності є те, що перенесена програма завжди запускається зі свого вихідного стану. Це відбувається, наприклад, з Java-aпплетами. Перевага подібного підходу в його простоті. Слабка мобільність потрібна лише для того, щоб машина, на яку переноситься код, була в змозі його виконувати. Цього цілком достатньо, аби зробити код переносним.

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

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

Приклад

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

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

Приклад

Java-апплети.

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

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

Приклад

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

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

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