Головна > Програми > Архітектура розподілених систем. Огляд розподілених систем Рівень обробки даних


Архітектура розподілених систем. Огляд розподілених систем Рівень обробки даних




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

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

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

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

Створено стандарт протоколу бездротового доступу додатків у Web (Wireless Application Protocol - WAP), який підтримується деякими моделями стільникових телефонів. На основі WAP та мови XMLКонсорціум W3C розробив мову розмітки для бездротових комунікацій WML (Wireless Markup Language).

У розробках АІС більше уваги приділяли метаданим. Тут робляться кроки у двох напрямках - стандартизація подання метаданих та забезпечення їх підтримки у системі.

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

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

Ймовірно, першим стандартом де-факто цієї категорії була мова опису даних CODASYL для баз даних мережної структури. З пізніших стандартів слід назвати: стандарт мови запитів SQLдля реляційних базданих, що містить визначення так званої інформаційної схеми – сукупності уявлень схем реляційних баз даних; компонент стандарту об'єктних базданих ODMG, що описує інтерфейси репозиторію об'єктних схем; міжнародний стандарт IRDS (Information Resource Dictionary Systems), що описує системи для створення та підтримки довідників інформаційних ресурсів організації.

Далі слід згадати розроблений консорціумом OMG стандарт CWM (Common Warehouse Metamodel) представлення метаданих сховищ даних, заснований на раніше створеному для більш широких цілей стандарті OIM (Open Information Model) консорціуму MDC (Meta Data Coalition).

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

До стандартів метаданих Web відноситься підмножина мови XML, що використовується для опису логічної структури XML-документів деякого типу. Цей опис називається DTD (Document Type Definition). Крім того, платформа XML включає стандарт XML Schema, що пропонує розвиненіші можливості для опису XML-документів. Стандарт RDF (Resource Definition Framework) визначає просту мову подання знань для опису вмісту XML-документів. Нарешті, стандарт OWL (Ontology Web Language) визначає формальну мову опису онтології, призначений для семантичного Web.

Стандарт мови UML (Unified Modeling Language), що забезпечує представлення метаданих CASE інструментів для візуального об'єктного аналізу та проектування, розроблений консорціумом OMG. Ця мова підтримується у багатьох програмних продуктах CASE. Консорціум OMG створив також стандарт XMI (XML Metadata Interchange) для обміну метаданими між інструментами CASE, які використовують мову UML.

Слід згадати тут також стандарт Дублінського ядра (Dublin Core – DC) – набору елементів метаданих для опису змісту документів різної природи. Цей стандарт швидко набув популярності і знайшов, зокрема, широке застосування серед Web (див. розд. 3.3).

Роботи з розвитку існуючих та створення нових стандартів подання метаданих для АІС продовжуються. Докладніші відомості про аналізовані стандарти можна знайти в енциклопедії.


на основі багатоконвеєрної, що реконфігурується обчислювального середовища L-Net

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

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

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

Узагальнена типова архітектура розподіленої системи управління (РСУ) включає три ієрархічно пов'язаних рівня: операторський рівень, рівень управління і рівень введення-виведення (див. рис.1) .

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

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

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

Вимоги до РСУ

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

Огляд архітектури РСУ

Для проведення огляду архітектури РСУ були обрані РСУ Siemens SIMATIC PCS 7 як одна з найбільш затребуваних на ринку та RTS S3 як РСУ, реалізована на базі ОСРВ QNX.

Siemens SIMATIC PCS 7

Архітектура системи має всі властивості узагальненої архітектури РСУ. Як операторські станції виступають комп'ютери на базі процесорної архітектури x86 з ОС Windows і пакетом Siemens WinCC, що надає ЧМІ. Є сервери з базами даних. Станції операторів, інженерні станції та сервери пов'язані локальною мережею на основі Ethernet. Операторський рівень пов'язаний із рівнем управління зарезервованою мережею Industrial Ethernet. На рівні управління знаходяться програмовані логічні контролери (ПЛК) із можливістю резервування за рахунок дублювання функціоналу. Є можливість підключатися до зовнішніх систем та мереж та організувати віддалений доступдо системи.

RTS S3

Ця архітектура аналогічно складається з рівнів узагальненої структури РСУ. Операторські станції засновані на тій же апаратній платформі, що і в SIMATIC РСУ, але можуть перебувати під управлінням як ОС Windows, так і Linux. Інженерні станції поєднані з операторськими. Системою надається єдине середовище розробки програм. Мережа Ethernet з'єднує вузли всередині операторського рівня та сам операторський рівень із рівнем управління з використанням стека протоколів TCP/IP. На рівні управління знаходяться промислові комп'ютери під управлінням ОС QNX із власною базою даних та можливістю резервування шляхом дублювання функціоналу вузла.

Недоліки описаних систем

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

Характеристики та функціональні особливості системи L-Net

При розробці системи L-Net ставилося завдання створити таку систему управління, яка матиме нижчеперелічені характеристики:

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

Для побудови системи з описаними вище характеристиками потрібна операційна система, призначена переважно для створення систем управління і вбудованих систем. Аналіз існуючих операційних системпоказав, що найбільш підходящою операційною системою є ОС QNX 6 (Neutrino), яка має дуже ефективні ресурсорозподільні та мережеві можливості. Широкі мережеві можливості забезпечуються мережним протоколом Qnet. Він вирішує завдання надійності та динамічного балансування навантаження каналів зв'язку, але при цьому не вирішуються проблеми відмовостійкості системи в цілому. В результаті була розроблена інноваційна система управління, заснована на розподіленому багатоконвеєрному обчислювальному середовищі, що реконфігурується. Розроблена система має однорангову архітектуру, що включає три логічні блоки: блок введення-виводу, блок комутаторів загального призначенняі блок обчислювального середовища, що реконфігурується (РВС) (див. рис.2).

Основними перевагами даної архітектури є:

  • Одноранговий тип
  • Децентралізованість
  • Масштабованість
  • Просторова розподіленість

Функціональні особливості цієї архітектури:

  • Конвеєрна обробка даних
  • Апаратне резервування
  • Розподіл навантаження
  • Реконфігурація «на льоту»

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

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

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

Розподіл навантаження

Одним із основних завдань системи L-Net є розподіл обчислювального навантаження на вузлах мережі. Розв'язання цього завдання полягає в побудові обчислювальних конвеєрів. Для побудови обчислювального конвеєра попередньо будується графік завдання – схема обміну потоками даних від джерела до одержувача. Як джерело виступають датчики, а як одержувач – виконавчі механізми. Сам обчислювальний конвеєр є відображенням графа завдання (див. рис.3) на граф обчислювальної мережі (див. рис.4) з урахуванням вимог задачі до обчислювальних ресурсів системи та поточного її стану.

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

Відмовостійкість

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

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

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

Висновок

Розроблена система L-Net на відміну від існуючих аналогів передбачає використання широкого спектра апаратних характеристик вузлів РСУ за повної їхньої програмної сумісності. При роботі вузлів під управлінням однієї операційної системи (QNX Neutrino) забезпечується можливість їх побудови на різних процесорних архітектурах (x86, ARM, MIPS тощо) з різноманітними наборами інтерфейсів та периферійних пристроїв. Реалізація вузлів можлива у вигляді настільних, промислових ПК, ПК, що носяться, і одноплатних комп'ютерів. Усі складові комплексу програмного забезпечення РСУ можуть бути запущені на будь-якому її вузлі з ОС QNX, при цьому залишається можливість використання вузлів з іншою операційною системою. Такий підхід дозволяє використовувати кожен вузол для вирішення завдань операторського рівня, так і рівня управління. Отже, є гнучка система взаємодії між одноранговими вузлами без жорсткої ієрархії рівнів, властивої узагальненої архітектури РСУ та системам, що використовують цю архітектуру як базову. Одноранговість мережі спрощує процеси розгортання, експлуатації, масштабування та налагодження системи.

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

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

Висновок

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

  1. http://kazanets.narod.ru/DCSIntro.htm.
  2. http://kazanets.narod.ru/PCS7Overview.htm.
  3. http://www.rts.ua/ukr/news/678/0/409 .
  4. Зиль С. QNX Momentics: основи застосування. - СПб: БХВ-Петербург, 2005.
  5. Кртен Р. Вступ до QNX Neutrino. Посібник для розробки програм реального часу. - СПб: БХВ-Петербург, 2011.

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

Architecture of distributed control system базується на reconfigurable multi-pipeline computing environment L-Net

Sergey Yu. Potomskiy, Assistant Professor of National Research University «Higher School of Economics».

Nikita A. Poloyko, Fifth-year student of National Research University «Higher School of Economics». Study assistant. Programmer. Field of training: "Control and informatics in the technical systems".

Abstract.Цей матеріал є розвиненим для розповсюдженого системного контролю, заснованого на регенеруючій multi-pipeline computing environment. Архитектура системи є Given. Також, основними характеристиками і функціональними властивостями системи є Gito too. article presents a rationale for the choice of the operating system. Основні переваги системи в comparison with existing similar developments are shown in the article.

Keywords: distributed control system, systems software support, distributed reconfigurable.


Вконтакте

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

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

Розподілена архітектура AggreGate надзвичайно гнучка. Технічно вона заснована на формуванні однорангових зв'язків між серверами та прикріпленні частин єдиної моделі даних одних серверів («постачальників») до інших («споживачів»).

Цілі розподілених операцій

Основними цілями розподіленої архітектури є:

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

Розподіл ролей сервера

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

Великомасштабна хмарна IoT-платформа

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

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

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

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

Багаторівнева інфраструктура Інтернету речей

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

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

Управління розумним містом

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

  • Рівень 1: фізичне обладнання (мережеві маршрутизатори, контролери, промислове обладнання тощо)
  • Рівень 2: сервери управління (сервери моніторингу мережі, сервери контролю доступу, сервери автоматизації будівель та інші)
  • Рівень 3: центри управління серверами будівель (один сервер на будівлю, який збирає інформацію з усіх серверів другого рівня)
  • Рівень 4: сервери районів міста (кінцевий пункт призначення для ескалації оповіщень нижчого рівня, моніторинг у реальному часі, інтеграція з Service Desk-системами)
  • Рівень 5: сервери головного офісу (контроль серверів району, збір та узагальнення звітів, оповіщень)

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

Управління мультисегментною мережею

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

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

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

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

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

Високопродуктивне управління подіями

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

У подібних випадках один сервер AggreGate не впорається з усіма потоками подій. Організувати обробку подій допоможе розподілена архітектура:

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

Цифрове підприємство

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

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

Гетерогенні мультикомп'ютерні системи

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

Мережа, що з'єднує їх, також може бути сильно неоднорідною.

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

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

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

Найбільш ранньою та фундаментальною розподіленою архітектурою є «клієнт-сервер», в якій одна із сторін (клієнт) ініціює обмін даними, надсилаючи запит іншій стороні (серверу). Сервер обробляє запит і за необхідності посилає відповідь клієнту (рис. 2.7).

Рис. 2.7. Модель взаємодії клієнт сервер

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



Рис. 2.8. Логічні рівні програми

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

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

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

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

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

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

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

Рис. 2.11. Розподілена система роздрібного продажу

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

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

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

(Матеріал сайту http://se.math.spbu.ru)

Вступ.

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

Існує шість основних характеристик розподілених систем.

  1. Спільне використання ресурсів. Розподілені системи допускають спільне використання як апаратних (жорстких дисків, принтерів), і програмних (файлів, компіляторів) ресурсів.
  2. Відкритість.Це можливість розширення системи шляхом додавання нових ресурсів.
  3. Паралельність.У розподілених системах кілька процесів можуть одночасно виконуватися на різних комп'ютерах у мережі. Ці процеси можуть взаємодіяти під час виконання.
  4. Масштабованість . Під масштабованістюрозуміється можливість додавання нових властивостей та методів.
  5. Відмовостійкість. Наявність кількох комп'ютерів дозволяє дублювання інформації та стійкість до деяких апаратних та програмних помилок. Розподілені системи у разі помилки можуть підтримувати часткову функціональність. Повний збій у роботі системи відбувається лише при мережевих помилках.
  6. Прозорість.Користувачам надається повний доступдо ресурсів у системі, водночас від них прихована інформація про розподіл ресурсів у системі.

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

  1. Складність. Набагато важче зрозуміти та оцінити властивості розподілених систем загалом, їх складніше проектувати, тестувати та обслуговувати. Також продуктивність системи залежить від швидкості роботи мережі, а чи не окремих процесорів. Перерозподіл ресурсів може суттєво змінити швидкість роботи системи.
  2. Безпека. Зазвичай доступ до системи можна отримати з кількох різних машин, повідомлення в мережі можуть переглядатися та перехоплюватися. Тому у розподіленій системі набагато важче підтримувати безпеку.
  3. Керованість. Система може складатися з різнотипних комп'ютерів, на яких можна встановити різні версіїопераційні системи. Помилки на одній машині можуть поширитися непередбачуваним чином інші машини.
  4. Непередбачуваність . Реакція розподілених систем на деякі події непередбачувана і залежить від повного завантаження системи, її організації та навантаження. Так як ці параметри можуть змінюватися , тому час відповіді запит може істотно відрізнятися від часу.

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

  1. Ідентифікація ресурсів . Ресурси в розподілених системах розташовуються на різних комп'ютерах, тому систему імен ресурсів слід продумати так, щоб користувачі могли легко відкривати необхідні їм ресурси і посилатися на них. Прикладом може бути система URL(уніфікований покажчик ресурсів), що визначає імена Web-страниц.
  2. Комунікація. Універсальна працездатність Internet та ефективна реалізація протоколів TCP/IP в Internet для більшості розподілених систем є прикладом найбільш ефективного способу організації взаємодії між комп'ютерами. Однак у деяких випадках, коли потрібна особлива продуктивність або надійність, можливе використання спеціалізованих засобів.
  3. Якість системного сервісу . Цей параметр відображає продуктивність, працездатність та надійність. На якість сервісу впливає ряд факторів: розподіл процесів, ресурсів, апаратні засоби та можливості адаптації системи.
  4. Архітектура програмного забезпечення . Архітектура ПЗ описує розподіл системних функцій по компонентам системи, і навіть розподіл цих компонентів процесорам. Якщо потрібно підтримувати висока якістьсистемного сервісу вибір правильної архітектури є вирішальним фактором.

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

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

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

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

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

Спочатку кілька слів про те, що таке XML взагалі. XML – універсальний формат даних, який використовується для надання Web-сервісів. В основі Web-сервісів лежать відкриті стандарти та протоколи: SOAP, UDDI та WSDL.

  1. SOAP ( Simple Object Access Protocol), розроблений консорціумом W3C, визначає формат запитів до Web-сервісів. Повідомлення між Web-сервісом та його користувачем пакуються у звані SOAP-конверти (SOAP envelopes , іноді ще називають XML-конвертами). Саме повідомлення може містити або запит на здійснення дії, або відповідь - результат виконання цієї дії.
  2. WSDL (Web Service Description Language).Інтерфейс Web-сервісу описується в WSDL-документах (а WSDL - це підмножина XML). Перед розгортанням служби розробник складає її опис мовою WSDL, вказує адресу Web-сервісу, протоколи, що підтримуються, перелік допустимих операцій, формати запитів і відповідей.
  3. UDDI (Universal Description, Discovery and Integration) -протокол пошуку Web-сервісів в Internet ( http://www.uddi.org/). Є бізнес-реєстром, в якому провайдери Web-сервісів реєструють служби, а розробники знаходять необхідні сервіси для включення до своїх додатків.

З доповіді може здатися, що Web-сервіси - найкраще і безальтернативне рішення, і лише у виборі засобів розробки. Однак, це не так. Альтернатива Web-службам існує, це семантичний Web (Semantic Web), про необхідність створення якого вже п'ять років тому говорив автор WWW Тім Бернерс-Лі.

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

Список літератури

  1. СоммервіллІ. Інженерія програмного забезпечення.
  2. Драниця А. Java проти .NET. - "Комп'ютерра", # 516.
  3. Ресурси Інтернет.