Моделі розподілених мережевих систем

Модель клієнт-сервер

В базовій моделі клієнт-сервер всі процеси в розподілених системах діляться на дві групи. Процеси, які реалізують деяку службу, наприклад службу файлової системи чи бази даних, є серверами (servers). Процеси, які запитують служби у серверів шляхом надсилання відповідних запитів і подальшого очікування відповіді від серверу — клієнти (clients). Взаємодія між клієнтом та сервером також відома під назвою режим запит-відповідь (request-reply behavior). (рис. 2.3).

Рис. 2.3. Базова модель взаємодії «клієнт-сервер».

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

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

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

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

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

• — рівень користувацького інтерфейсу;
• — рівень обробки;
• — рівень даних.

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

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

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

Рис. 2.5. Логічні рівні прикладної програми.

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

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

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

Рівень обробки

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

Рівень даних

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

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

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

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

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

Варіанти архітектури клієнт-сервер

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

Рис. 2.6. Дволанкова архітектура.

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

Рис. 2.7. Триланкова архітектура.

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

Рис. 2.8. Розподілена система роздрібних продажів,.

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

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

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

Рис. 2.9. Система прямого обміну даними між клієнтами,.

де ІК — інтерфейс користувача, ЛП — логіка прикладних програм, ДД — доступ до даних, БД — база даних.

Багатоланкові архітектури клієнт-сервер

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

Рис. 2.10. Альтернативні форми організації архітектури клієнт-сервер.

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

Розглядаючи розподілення програмного забезпечення на клієнтське і серверне, необхідно враховувати те, що сервер іноді має працювати як клієнт. Така ситуація, зображена на рис. 2.11, приводить до фізично триланкової архітектури (physically three-tiered architecture).

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

Рис. 2.11. Приклад сервера, що діє як клієнт.

Сучасні варіанти архітектури клієнт-сервер

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

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

Як розповсюджений приклад горизонтального розподілу розглянемо web-сервер, реплікований на кілька машин локальної мережі, як показано на рис. 2.12. На кожному із серверів утримується той самий набір web-сторінок, і щораз, коли одна з web-сторінок обновлюється, її копії одразу розсилаються на всі сервери. Сервер, якому буде переданий вхідний запит, вибирається за правилом «каруселі» (round-robin). Ця форма горизонтального розподілу досить успішно використовується для вирівнювання навантаження на сервери популярних web-сайтів. У такий же спосіб, хоча й менш очевидно, можуть бути розподілені й клієнти.

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