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

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

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

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

Рис. 1.1.

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

Рис. 1.2.

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

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

Рис. 1.3.

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

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

Рис. 1.4.

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

У попередній главі нами були розглянуті сильнопов'язані багатопроцесорні системи із загальною пам'яттю, загальними структурами даних ядра та загальним пулом, з якого процеси викликаються на виконання. Часто, однак, буває бажано для забезпечення спільного використання ресурсів розподіляти процесори таким чином, щоб вони були автономні від операційного середовища та умов експлуатації. Нехай, наприклад, користувачеві персональної ЕОМ потрібно звернутися до файлів, що знаходяться на більшій машині, але зберегти при цьому контроль над персональною ЕОМ. Незважаючи на те, що окремі програми, такі як uucp, підтримують передачу файлів через мережу та інші мережеві функції, їх використання не буде приховано від користувача, оскільки користувач знає про те, що він працює в мережі. Крім того, треба зауважити, що програми, подібні до текстових редакторів, з віддаленими файлами, як зі звичайними, не працюють. Користувачі повинні мати стандартний набір функцій системи UNIX і, за винятком можливої ​​втрати у швидкодії, не повинні відчувати перетину машинних кордонів. Так, наприклад, робота системних функцій open і read з файлами на віддалених машинах не повинна відрізнятися від їхньої роботи з файлами, що належать локальним системам.

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

Малюнок 13.1. Модель системи із розподіленою архітектурою

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

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

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

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

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

13.1 ПЕРИФЕРІЙНІ ПРОЦЕСОРИ

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

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

Малюнок 13.2. Конфігурація периферійної системи

Малюнок 13.3. Формати повідомлень

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

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

Для того, щоб пояснити, як працює периферійна система, розглянемо ряд функцій: getppid, open, write, fork, exit і signal. Функція getppid досить проста, оскільки вона пов'язана з простими формами запиту та відповіді, якими обмінюються периферійний та центральний процесори. Ядро на периферійному процесорі формує повідомлення, що має ознаку, з якого випливає, що функцією, що запитується, є функція getppid, і посилає запит центральному процесору. Процес-супутник на центральному процесорі читає повідомлення з периферійного процесора, розшифровує тип системної функції, виконує її та отримує ідентифікатор свого батька. Потім він формує відповідь і передає його периферійного процесу, що знаходиться в стані очікування на іншому кінці лінії зв'язку. Коли периферійний процесор отримує відповідь, він передає його процесу, що спричинив системну функцію getppid. Якщо ж периферійний процес зберігає дані (такі, як ідентифікатор процесу-батька) у локальній пам'яті, йому взагалі доведеться зв'язуватися зі своїм супутником.

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

Малюнок 13.4. Виклик функції open із периферійного процесу

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

Єдиною функцією, яка потребує внесення змін під час роботи на центральному процесорі, є системна функція fork. Коли процес виконує цю функцію на ЦП, ядро ​​вибирає йому периферійний процесор і посилає повідомлення спеціальному процесу - серверу, інформуючи останній у тому, що збирається розпочати вивантаження поточного процесу. Припускаючи, що сервер прийняв запит, ядро ​​за допомогою функції fork створює новий периферійний процес, виділяючи запис у таблиці процесів та адресний простір. Центральний процесор вивантажує копію процесу, що викликав функцію fork, на периферійний процесор, затираючи щойно виділений адресний простір, породжує локальний супутник зв'язку з новим периферійним процесом і посилає на периферію повідомлення необхідність ініціалізації лічильника команд нового процесу. Процес-супутник (на ЦП) є нащадком процесу, що спричинив функцію fork; периферійний процес з технічної точки зору виступає нащадком процесу-сервера, але за логікою є нащадком процесу, що викликав функцію fork. Процес-сервер немає логічного зв'язку з нащадком після завершення функції fork; єдине завдання сервера полягає у наданні допомоги при розвантаженні нащадка. Через сильний зв'язок між компонентами системи (периферійні процесори не мають автономії) периферійний процес і процес-супутник мають один і той же код ідентифікації. Взаємозв'язок між процесами показаний на Рисунку 13.5: безперервною лінією показано зв'язок типу "батько-нащадок", пунктиром - зв'язок між рівноправними партнерами.

Малюнок 13.5. Виконання функції fork на центральному процесорі

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

Малюнок 13.6. Виконання функції fork на периферійному процесорі

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

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

алгоритм sighandle /* алгоритм обробки сигналів */

if (поточний процес є чиїмось супутником або має прототип)

if (сигнал ігнорується)

if (сигнал надійшов під час виконання системної функції)

поставити сигнал перед процесом-супутником;

надіслати повідомлення про сигнал периферійного процесу;

else ( /* периферійний процес */

/* надійшов сигнал під час виконання системної функції чи ні */

надіслати сигнал процесу-супутнику;

алгоритм satellite_end_of_syscall /* завершення системної функції, спричиненої периферійним процесом */

вхідна інформація: відсутня

вихідна інформація: відсутня

if (під час виконання системної функції надійшло переривання)

надіслати периферійному процесу повідомлення про переривання, сигнал;

else /* виконання системної функції не переривалося */

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

Рисунок 13.7. Обробка сигналів у периферійній системі

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

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

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

3. Якщо після отримання сигналу процес-супутник перериває виконання системної функції (longjmp), він інформує про це периферійний процес і повідомляє йому номер сигналу.

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

Рисунок 13.8. Переривання під час виконання системної функції

Припустимо, наприклад, що периферійний процес викликає функцію читання з терміналу, пов'язаного з центральним процесором, і зупиняє роботу на час виконання функції процесом-супутником (Рисунок 13.8). Якщо користувач натискає клавішу переривання (break), ядро ​​ЦП посилає процес-супутнику відповідний сигнал. Якщо супутник перебував у стані приостанова в очікуванні введення з терміналу порції даних, він негайно виходить із цього стану та припиняє виконання функції read. У своїй відповіді на запит периферійного процесу супутник повідомляє код помилки та номер сигналу, що відповідає перериванню. Периферійний процес аналізує відповідь і оскільки в повідомленні йдеться про надходження сигналу переривання, відправляє сигнал самому собі. Перед виходом із функції read периферійне ядро ​​здійснює перевірку надходження сигналів, виявляє сигнал переривання, що надійшов від процесу-супутника, та обробляє його звичайним порядком. Якщо в результаті отримання сигналу переривання периферійний процес завершує свою роботу за допомогою функції exit, ця функція бере турботу про знищення процесу-супутника. Якщо периферійний процес перехоплює сигнали про переривання, він викликає функцію обробки сигналів і по виході з функції read повертає користувачеві код помилки. З іншого боку, якщо супутник виконує від імені периферійного процесу системну функцію stat, він не перериватиме її виконання при отриманні сигналу (функції stat гарантований вихід з будь-якого призупину, оскільки для неї час очікування ресурсу обмежений). Супутник доводить виконання функції остаточно і повертає периферійному процесу номер сигналу. Периферійний процес посилає сигнал самому собі та отримує його на виході із системної функції.

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

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

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

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

13.2 ЗВ'ЯЗОК ТИПУ NEWCASTLЕ

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

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

"sftig!/fs1/mjb/rje"

ідентифікує файл "/fs1/mjb/rje", що знаходиться на машині "sftig". Така схема ідентифікації файлу відповідає угоді, встановленій програмою uucp щодо передачі файлів між системами типу UNIX. В іншій схемі видалені файли ідентифікуються додаванням до імені спеціального префікса, наприклад:

/../sftig/fs1/mjb/rje

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

Малюнок 13.9. Формулювання запитів до файлового сервера (процесора)

Всю частину розділу, що залишилася, ми присвятимо розгляду моделі системи, що використовує зв'язок типу Newcastle, в якій ядро ​​не займається розпізнаванням віддалених файлів; ця функція повністю покладається на підпрограми зі стандартної Бібліотеки, що виконують у цьому випадку роль системного інтерфейсу. Ці підпрограми аналізують першу компоненту імені файлу в обох описаних способах ідентифікації містить ознаку віддаленості файлу. У цьому полягає відступ від закладеного порядку, у якому бібліотечні підпрограми займаються синтаксичним розбором імен файлів. На малюнку 13.9 показано, як формулюються запити до файлового серверу. Якщо файл локальний, ядро ​​локальної системи обробляє запит у звичайний спосіб. Розглянемо зворотний випадок:

open("/../sftig/fs1/mjb/rje/file", O_RDONLY);

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

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

Більш делікатним питанням є отримання роботи з віддаленими файлами прав суперкористувача. З одного боку, клієнт-суперкористувач не повинен мати ті ж права щодо віддаленої системи, щоб не вводити в оману засоби захисту віддаленої системи. З іншого боку, деякі програми, якщо їм не надати права суперкористувача, просто не зможуть працювати. Прикладом такої програми є програма mkdir (див. Розділ 7), що створює новий каталог. Віддалена система не дозволила б клієнту створювати новий каталог, оскільки видалення права суперкористувача не діють. Проблема створення віддалених каталогів є серйозною основою для перегляду системної функції mkdir у бік розширення її можливостей автоматичного встановлення всіх необхідних користувачеві зв'язків. Тим не менш, отримання setuid-програмами (до яких відноситься і програма mkdir) прав суперкористувача по відношенню до віддалених файлів все ще залишається загальною проблемою, яка потребує вирішення. Можливо, що найкращим вирішенням цієї проблеми було б встановлення файлів додаткових характеристик, що описують доступ до них з боку віддалених суперкористувачів; на жаль, це потребувало б внесення змін до структури дискового індексу (у частині додавання нових полів) і породило б занадто великий безлад у існуючих системах.

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

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

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

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

13.3 "ПРОЗРАЧНІ" РОЗПОДІЛЕНІ ФАЙЛОВІ СИСТЕМИ

Термін "прозорий розподіл" означає, що користувачі, що працюють на одній машині, можуть звертатися до файлів, що знаходяться на іншій машині, не усвідомлюючи того, що цим вони перетинають машинні межі, подібно до того, як на своїй машині вони при переході від однієї файлової У системі до іншої перетинають точки монтування. Імена, за якими процеси звертаються до файлів, що знаходяться на віддалених машинах, схожі на імена локальних файлів: відмітні символи в них відсутні. У конфігурації, показаній на Рисунку 13.10, каталог "/usr/src", що належить машині B, "вмонтований" у каталог "/usr/src", що належить машині A. Така конфігурація є зручною в тому випадку, якщо в різних системах передбачається використовувати один і той же вихідний код системи, що традиційно знаходиться в каталозі "/usr/src". Користувачі, що працюють на машині A, можуть звертатися до файлів, розташованих на машині B, використовуючи звичний синтаксис написання імен файлів (наприклад: "/usr/src/cmd/login.c"), і ядро ​​вже вирішує питання, є файл видаленим або ж локальним. Користувачі, що працюють на машині B, мають доступ до своїх локальних файлів (не підозрюючи про те, що до цих файлів можуть звертатися і користувачі машини A), але, у свою чергу, не мають доступу до файлів, що знаходяться на машині A. Звичайно , можливі й інші варіанти, зокрема, такі, у яких всі віддалені системи монтуються в корені локальної системи, завдяки чому користувачі отримують доступ до всіх файлів у всіх системах.

Малюнок 13.10. Файлові системи після віддаленого монтування

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

Цікава проблема пов'язана з іменами шляхів, що включають ".." Якщо процес робить поточним каталог з віддаленої файлової системи, подальше використання імені символів ".." швидше поверне процес у локальну файлову систему, ніж дозволить звертатися до файлів, розташованим вище поточного каталогу. Повертаючись знову до Рисунку 13.10, відзначимо, що коли процес, що належить машині A, вибравши попередньо як поточний каталог "/usr/src/cmd", розташований у віддаленій файловій системі, виконає команду

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

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

Малюнок 13.11. Відкриття віддаленого файлу

Розглянемо процес, що відкриває віддалений файл "/usr/src/cmd/login.c", де "src" - точка монтування. Виконуючи синтаксичний аналіз імені файлу (за схемою namei-iget), ядро ​​виявляє, що файл видалений, і посилає на машину, де він знаходиться, запит на отримання заблокованого індексу. Отримавши бажану відповідь, локальне ядро ​​створює у пам'яті копію індексу, що кореспондує з віддаленим файлом. Потім ядро ​​проводить перевірку наявності необхідних прав доступу до файлу (на читання, наприклад), надіславши на віддалену машину ще одне повідомлення. Виконання алгоритму open продовжується у повній відповідності з планом, наведеним у розділі 5, з надсиланням повідомлень на віддалену машину в міру необхідності, до завершення алгоритму та звільнення індексу. Взаємозв'язок між структурами даних ядра після завершення алгоритму open показано на малюнку 13.11.

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

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

У випадку із системною функцією open запит на виконання функції, що посилається на віддалену машину, включає частину імені файлу, що залишилася після виключення компонент імені шляху пошуку, що відрізняють віддалений файл, а також різні прапори. У розглянутому прикладі з відкриттям файлу "/usr/src/cmd/login.c" ядро ​​посилає на віддалену машину ім'я "cmd/login.c". Повідомлення також включає в себе розпізнавальні дані, такі як код користувача і груповий ідентифікації, необхідні для перевірки прав доступу до файлів на віддаленій машині. Якщо з віддаленої машини надходить відповідь, що свідчить про успішне виконання функції open, локальне ядро ​​вибирає вільний індекс у пам'яті локальної машини і помічає його як індекс віддаленого файлу, зберігає інформацію про віддалену машину та віддалений індекс і по заведеному порядку виділяє новий запис у таблиці файлів. У порівнянні з реальним індексом на віддаленій машині індекс, що належить локальній машині, є формальним, що не порушує конфігурацію моделі, яка в цілому співпадає зі конфігурацією, яка використовується при виклику віддаленої процедури (Малюнок 13.11). Якщо функція, що викликається процесом, звертається до віддаленого файлу за його дескриптором, локальне ядро ​​дізнається з індексу (локального) про те, що файл віддалений, формулює запит, що включає в себе викликану функцію, і посилає його на віддалену машину. У запиті міститься покажчик на віддалений індекс, яким процес-супутник зможе ідентифікувати сам віддалений файл.

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

13.4 РОЗПОДІЛЕНА МОДЕЛЬ БЕЗ ПЕРЕДАЧНИХ ПРОЦЕСІВ

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

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

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

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

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

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

Малюнок 13.12. Концептуальна схема взаємодії з віддаленими файлами на рівні ядра

13.5 ВИСНОВКИ

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

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

13.6 ВПРАВИ

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

2. Процеси що неспроможні ігнорувати сигнали типу SIGKILL; поясніть, що відбувається у периферійній системі, коли процес отримує такий сигнал.

*3. Опишіть реалізацію системної функції exec у системі з периферійними процесорами.

*4. Як центральному процесору слід проводити розподіл процесів між периферійними процесорами для того, щоб збалансувати загальне навантаження?

*5. Що станеться у тому випадку, якщо у периферійного процесора не виявиться достатньо пам'яті для розміщення всіх вивантажених на нього процесів? Яким чином повинні проводитися вивантаження та підкачування процесів у мережі?

6. Розглянемо систему, в якій запити до віддаленого файлового сервера надсилаються у разі виявлення імені файлу спеціального префікса. Нехай процес викликає функцію execl("/../sftig/bin/sh", "sh", 0); Модуль, що виконується, знаходиться на віддаленій машині, але повинен виконуватися в локальній системі. Поясніть, яким чином віддалений модуль переноситься до локальної системи.

7. Якщо адміністратору потрібно додати до існуючої системи зв'язку типу Newcastle нові машини, то як про це найкраще поінформувати модулі Сі-бібліотеки?

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

*9. Як показано в розділі 13.2, виклик системної функції exit у системах із зв'язком типу Newcastle призводить до посилки повідомлення процесу-супутнику, що змушує останній завершити свою роботу. Це робиться на рівні бібліотечних підпрограм. Що відбувається, коли локальний процес отримує сигнал, що спонукає його завершити свою роботу як ядра?

*10. Як у системі зі зв'язком типу Newcastle, де видалені файли ідентифікуються додаванням до імені спеціального префікса, користувач може, вказавши як компонент імені файлу ".." (батьківський каталог), перетнути віддалену точку монтування?

11. З глави 7 відомо про те, що різні сигнали спонукають процес скидати дамп вмісту пам'яті в поточний каталог. Що має статися у тому випадку, якщо поточним є каталог із віддаленої файлової системи? Яку відповідь ви дасте, якщо в системі використовується зв'язок типу Newcastle?

*12. Які наслідки для локальних процесів мало б видалення із системи всіх процесів-супутників чи серверів?

*13. Подумайте над тим, як у "прозорій" розподіленій системі слід реалізувати алгоритм link, параметрами якого можуть бути два імені віддалених файлів, а також алгоритм exec, пов'язаний із виконанням кількох внутрішніх операцій читання. Розгляньте дві форми зв'язку: виклик віддаленої процедури та виклик віддаленої системної функції.

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

Малюнок 13.13. Конфігурація з термінальним сервером

*15. Коли користувач реєструється в системі, дисципліна термінальної лінії зберігає інформацію про те, що термінал є операторським, що веде групу процесів. Тому, коли користувач на клавіатурі терміналу натискає клавішу "break", сигнал переривання отримують всі процеси групи. Розглянемо конфігурацію системи, де всі термінали фізично підключаються до однієї машині, але реєстрація користувачів логічно реалізується інших машинах (Малюнок 13.13). У кожному окремому випадку система створює віддалений термінал getty-процес. Якщо запити до віддаленої системи обробляються за допомогою набору процесів-серверів, слід зазначити, що під час процедури відкриття сервер зупиняється в очікуванні підключення. Коли виконання функції open завершується, сервер повертається назад до серверного пулу, розриваючи свій зв'язок з терміналом. Яким чином здійснюється розсилання сигналу про переривання, викликаного натисканням клавіші "break", на адреси процесів, що входять до однієї групи?

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

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

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

*19. Коли процес звертається до віддаленого файлу, не виключена можливість, що у пошуках файлу процес обійде кілька машин. Як приклад візьмемо ім'я "/usr/src/uts/3b2/os", де "/usr" - каталог, що належить машині A, "/usr/src" - точка монтування кореня машини B, "/usr/src/uts /3b2" - точка монтування кореня машини C. Прохід через кілька машин до місця кінцевого призначення називається "мультіскачком" (multihop). Однак, якщо між машинами A і C існує безпосередній мережевий зв'язок, пересилання даних через машину B було б неефективним. Опишіть особливості реалізації "мультискачка" у системі зі зв'язком Newcastle та у "прозорій" розподіленій системі.

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

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

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

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

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

Компоненти керованої розподіленої архітектури

Механізми міжсистемної взаємодії (DCI)

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

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

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

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

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

Федеративний пошук

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

Федеративний пошук дозволяє:

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

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

Центр адміністрування служб DIRECTUM

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

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

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

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

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

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

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

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

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

ІС можна уявити таку, що складається з наступних складових частин (Рис. III-16)

ІІІ.03.2. a Файл-серверні програми.

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

Плюси:

Плюси файл-серверної архітектури:

Простота організації;

Не суперечить необхідним вимогам до БД підтримки цілісності і надійності.

Перевантаження мережі;

Непередбачуваність реакцію запит.

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

ІІІ.03.2. b Клієнт-серверні програми.

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

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

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

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

ІІІ.03.2. c Дво- та трирівневі архітектури клієнт-сервер.

Усі розглянуті вище архітектури є дворівневими. Вони різниться рівень клієнта і рівень сервера. Строго кажучи, ІС складається із трьох логічних рівнів:

· Рівень користувача;

· Рівень програми:

· Рівень даних.

Тому у дворівневій моделі, де задіяні лише два рівні, виникає проблема з масштабованістю та продуктивністю, якщо обрана модель тонкий клієнт, або проблеми пов'язані з управлінням системи, якщо взято модель товстий клієнт. Уникнути цих проблем можна, якщо застосовувати модель, що складається з трьох рівнів, де два з них сервери (Мал. III-21).

Сервер даних

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

Таблиця III‑5 Застосування різних типів архітектур

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

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

ІІІ.03.2. d Архітектура розподілених об'єктів.

p align="justify"> Більш загальний підхід забезпечує архітектура розподілених об'єктів, основними компонентами якої є об'єкти. Вони пропонують набір послуг через свої інтерфейси. Інші об'єкти надсилають запити, у своїй немає різниці між клієнтом і сервером. Об'єкти можуть розташовуватися на різних комп'ютерах у мережі та взаємодіяти за допомогою проміжного ПЗ, за аналогією системної шини, яка дозволяє підключати різні пристрої та підтримувати взаємодію між апаратними пристроями.

…

Диспетчер драйвер ODBC

Драйвер 1

Драйвер К

БД 1

БД К

Робота з SQL

…

Архітектура ODBC включає компоненти:

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

2. Диспетчер пристроїв. Він завантажує драйвера на вимогу додатків, пропонує єдиний інтерфейс усім додаткам, причому інтерфейс адміністратора ODBC однаковий і незалежний від того, з якою СУБД додаток буде взаємодіяти. Диспетчер драйверів, що поставляється Microsoft, є бібліотекою DLL, що динамічно завантажується.

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

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

Динамічна модель

Ця модель передбачає багато аспектів, для представлення яких мовою UML використовується як мінімум 5 діаграм див. 2.04.2-2.04.5.

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

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

Можна виділити два основних типи управління у програмних системах.

1. Централізоване управління.

2. Управління, засноване на подіях.

Централізоване управління може бути:

· Ієрархічним- за принципом «виклик-повернення» (саме так найчастіше працює навчальні програми)

· Модель диспетчераяка застосовується для паралельних систем.

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

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

Прикладом такого управління є організація програм у Windows.

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

Користувальницький інтерфейс

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

ІІІ.03.4. a Психофізичні особливості людини, пов'язані зі сприйняттям та обробкою інформації.

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

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

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

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

Короткострокова пам'ять – найвужче місце у системі обробки інформації людини. Її ємність дорівнює 7±2 незв'язаних об'єктів. Незатребувана інформація зберігається у ній трохи більше 30 секунд. Щоб не забути якусь важливу для нас інформацію, ми зазвичай повторюємо її про себе, оновлюючи інформацію у короткостроковій пам'яті. Таким чином, при проектуванні інтерфейсів слід мати на увазі, що переважній більшості складно, наприклад, запам'ятати та ввести на іншому екрані числа, що містять понад п'ять цифр.

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

ІІІ.03.4. b Основні критерії оцінки інтерфейсів

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

1) простоту освоєння та запам'ятовування - конкретно оцінюють час освоєння та тривалість збереження інформації та пам'яті;

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

3) суб'єктивну задоволеність при експлуатації системи (зручність роботи, стомлюваність тощо).

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

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

ІІІ.03.4. c Типи інтерфейсів користувача

Розрізняють такі типи інтерфейсів користувача:

Примітивні

Зі вільною навігацією

Прямого маніпулювання.

Інтерфейс примітивний

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

Інтерфейс меню.

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

Принципи створення системи обробки інформації у масштабі підприємства

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

Рис. 1. Схема розподілених обчислень

Проте практична реалізація ідеї з'єднання комп'ютерів у кластери та мережі гальмувалась відсутністю технічних рішень і насамперед необхідністю створення стандартів та протоколів взаємодії. Як відомо, перші ЕОМ з'явилися наприкінці сорокових років ХХ століття, а перша комп'ютерна мережа ARPANet, що зв'язала кілька комп'ютерів на території США, - тільки в 1966 р., майже через двадцять років. Звичайно, таке об'єднання обчислювальних можливостей сучасну розподілену архітектуру нагадувало дуже віддалено, проте це був перший крок у правильному напрямку.

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

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

Саме в цей період стало очевидним, що основними перевагами розподілених додатків є:

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

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

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

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

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

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

Парадигма розподілених обчислень

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

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

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

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

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

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

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

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

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

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

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

· Керованість - має на увазі здатність системи ефективно контролювати свої складові частини. Це досягається завдяки використанню керуючого ПЗ;

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

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

· Розширюваність - до розподілених програм можна додавати нові складові (серверне ПЗ) з новими функціями.

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

Рис. 2. Основні рівні архітектури розподіленої програми

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

Архітектура розподілених додатків

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

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

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

· Обробка даних (проміжний рівень, middleware). На цьому рівні сконцентрована бізнес-логіка програми, здійснюється управління потоками даних та організується взаємодія елементів програми. Саме концентрація всіх функцій обробки даних та управління на одному рівні вважається основною перевагою розподілених додатків;

· Зберігання даних (рівень даних). Це рівень серверів бази даних. Тут розташовані сервери, бази даних, засоби доступу до даних, різні допоміжні інструменти.

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

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

Рис. 3. Розподіл бізнес-логіки за рівнями розподіленої програми

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

Таким чином, можна виділити чотири основні рівні розподіленої архітектури (див. рис. 2):

· Подання даних (користувацький рівень);

· Правила бізнес-логіки (рівень обробки даних);

· Управління даними (рівень управління даними);

· Зберігання даних (рівень зберігання даних).

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

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

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

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

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

Розподіл бізнес-логіки за рівнями розподіленої програми

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

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

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

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

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

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

Рівень представлення даних

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

· отримання даних;

· Подання даних для перегляду користувачем;

· Редагування даних;

· Перевірка коректності введених даних;

· Збереження зроблених змін;

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

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

Рівень обробки даних

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

· Обробка потоків даних відповідно до бізнес-правил;

· Взаємодія з рівнем подання даних для отримання запитів та повернення відповідей;

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

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

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

Рівень керування даними

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

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

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

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

Отже, до функцій рівня управління даними належать:

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

· Управління з'єднаннями та каналами зв'язку між частинами програми;

· управління потоками даних між клієнтами та серверами та між серверами;

· Управління навантаженням;

· Реалізація системних служб програми.

Необхідно відзначити, що часто рівень управління даними створюється на основі готових рішень, що поставляються ринку програмного забезпечення різними виробниками. Якщо розробники вибрали для своєї програми архітектуру CORBA, то в її складі є брокер об'єктних запитів (Object Request Broker, ORB), якщо платформу Windows, - до їх послуг різноманітні інструменти: технологія COM+ (розвиток технології Microsoft Transaction Server, MTS), технологія обробки черг повідомлень MSMQ, технологія Microsoft BizTalk та ін.

Рівень зберігання даних

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

· Зберігання даних у БД та підтримання їх у працездатному стані;

· Обробка запитів рівня обробки даних та повернення результатів;

· Реалізація частини бізнес-логіки розподіленого додатку;

· Управління розподіленими базами даних за допомогою адміністративного інструментарію серверів БД.

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

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

Підключення до баз даних серверів SQL здійснюється в основному за допомогою клієнтського програмного забезпечення серверів. Крім цього, додатково можуть використовуватися різні технології доступу до даних, наприклад ADO (ActiveX Data Objects) або ADO.NET. Але при проектуванні системи необхідно враховувати, що функціонально-проміжні технології доступу до даних не відносяться до рівня зберігання даних.

Розширення базових рівнів

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

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

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

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

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

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

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