- •Розподілені системи
- •Історична довідка
- •Базові терміни та визначення
- •Телекомунікаційні мережі як елемент розподілених систем
- •Модель клієнт–сервер
- •1.3. Особливості розподілених систем
- •Переваги розподілених систем
- •Недоліки розподілених систем
- •Класифікація розподілених систем
- •Характеристики розподілених систем
- •Висновки
- •Запитання для самоконтролю
- •Розподілене середовище
- •Концепції апаратних рішень
- •Архітектура багатопроцесорних систем
- •Системи зі спільною пам’яттю
- •Системи з роздільною пам’яттю
- •Топології багатопроцесорних систем
- •Концепції програмних рішень
- •Та засобів проміжного рівня
- •Операційні системи й розподіленість
- •Проміжне середовище
- •2.5. Поняття розподіленого середовища
- •Розподіл прикладних програм за рівнями
- •Варіанти архітектури клієнт–сервер
- •Програмні компоненти розподілених систем
- •Основи мережної взаємодії
- •2.6. Взаємодія компонент розподіленої системи
- •Концепції взаємодії компонент розподіленої системи
- •Обмін повідомленнями
- •Віддалений виклик процедур
- •Використання віддалених об’єктів
- •Розподілені події
- •Розподілені транзакції
- •Безпека в розподілених системах
- •Опис інтерфейсу програмної компоненти
- •Мова і схеми Extensible Markup Language
- •Soap: мова повідомлень розподіленої системи
- •Wsdl: опис інтерфейсу програмної компоненти
- •Базові технології подання інформації в розподілених системах
- •Вимоги до прикладних програм серверної сторони
- •Висновки
- •Запитання для самоконтролю
- •Рівні протоколів
- •Низькорівневі протоколи
- •Транспортні протоколи
- •Протоколи верхнього рівня
- •Віддалений виклик процедур
- •Виклик локальної процедури та повернення результату
- •Звертання до віддалених об’єктів
- •Розподілені об’єкти
- •Прив’язка клієнта до об’єкта
- •Статичне й динамічне віддалене звертання до методів
- •Передача параметрів
- •1.4 Зв’язок на основі потоків даних
- •Підтримка безперервних середовищ
- •Потік даних
- •Синхронізація потоків даних
- •1.5 Протоколи проміжного рівня
- •Протокол soap
- •Сімейство протоколів xmpp
- •Протокол umsp
- •Висновки
- •Запитання для самоконтролю
- •2. Процеси
- •Потоки виконання. Визначення і структура
- •Стан процесів та потоків виконання
- •Реалізація потоків виконання
- •Потоки виконання в нерозподілених системах
- •Потоки виконання в розподілених системах
- •Багатопотокові клієнти
- •Багатопотокові сервери
- •Інтерфейси користувача
- •Клієнтське програмне забезпечення і прозорість розподілу
- •4.6 Сервери
- •Підходи до побудови серверів прикладного програмного забезпечення
- •Сервери об’єктів
- •Частина 2
- •Представлення додатка розподіленної системи
- •Рівнева організація додатку
- •Рівнева організація, застосування, виділення рівнів
- •Використання рівня Сервісів(Services Layer)
- •Дизайн рівневої структури
- •Вибір стратегії розбиття на рівні
- •Визначення наскрізної функціональності
- •Визначення інтерфейсу між рівнями
- •Вибір стратегії реалізації і впровадження
- •Вибір протоколів взаємодії
- •3. Дизайн Рівню Представлення
- •Дизайн рівня представлення включає наступні кроки:
- •Специфічні проблеми дизайну рівня представлення
- •Кешування
- •Комунікації
- •Композиція
- •Управління виключеннями
- •User Experience(Зручність Використання)
- •Інтерфейс користувача
- •Перевірка даних вводу користувача (Validation)
- •Batching(Пакетування)
- •З'єднання
- •Формат даних
- •Управління виключеннями
- •Реляційне відображення об'єктів(Object Relational Mapping)
- •Процедури, що зберігаються
- •Транзакції
- •Перевірка вводу
- •Типи бізнес-процесів
- •Загальні правила складання сміття:
- •Вибір стратегії визначення виключень
- •Стратегія протоколювання виключень
- •Стратегія повідомлення про виключення
- •Ухвалення рішення про необхідність обробки необроблених виключень
- •Спеціальні питання проектування
- •Аутентифікація
- •Авторизація
- •Кешування
- •Мережева взаємодія
- •Управління конфігурацією
- •Управління виключеннями
- •Протоколювання
- •Управління станом
- •Проблеми, які виникають при проектуванні взаємодії
- •Загальні завдання проектування стратегії зв'язку
- •Обмін файлами
- •Розподілена база даних
- •Виклик видалених процедур
- •Обмін повідомленнями
- •Процедура передачі повідомлення включає 5 основних етапів:
- •Комерційні системи обміну повідомленнями
-
Архітектура багатопроцесорних систем
Серед усієї різноманітності багатопроцесорних систем розглянемо системи типу MIMD (множинні потоки команд і множинні потоки даних). Обчислювальні системи типу MIMD являють собою об’єднання процесорів, на кожному з яких може бути запущена своя, відмінна від інших, програма,
що оперує власними даними. З огляду на це MIMD системи можна поділити на два класи: зі спільною пам’яттю і з роздільною пам’яттю.
-
Системи зі спільною пам’яттю
У системах зі спільною пам’яттю програма поділена на процеси, які взаємодіють і автоматично розподіляються між доступними процесорами системи. Для систем цього класу є засоби автоматизованої побудови парале- льних програм – векторизуючі компілятори. Достатньо широке коло послідов- них алгоритмів може бути успішно адаптовано до функціонування на систе- мах зі спільною або з розподільною пам’яттю (рис. 2.1). Система зі спільною пам’яттю зручна тому, що функціонує під єдиною копією операційної системи й не вимагає індивідуального налаштування кожного процесорного вузла. Такі комп’ютери, керовані Unіx або подібними операційними системами, обслуговують користувачів у режимі колективного користування, автома- тично розподіляючи потік завдань прикладного програмного забезпечення процесорами без участі адміністратора або оператора.
Рис. 2.1. Багатопроцесорна система зі спільною пам’яттю
Системам зі спільною пам’яттю властива низка істотних недоліків:
СпІльна оперативна пам`ять
-
порівняно невелика кількість процесорів;
-
немає можливості збільшення кількості процесорів, тобто масштабува- ти систему;
-
пікова продуктивність найбільших систем зі спільною пам’яттю нижча від пікової продуктивності найбільших систем із роздільною пам’яттю;
-
висока вартість порівняно з аналогічними за продуктивністю система- ми з роздільною пам’яттю.
Ефективно об’єднати більше 20–30 процесорів на основі загальної пам’яті важко, оскільки кожний процесор повинен мати фізичний доступ до кожного з блоків оперативної пам’яті.
Приклад. У разі використання роздільних 32-розрядної адресної ши- ни й
64-розрядної шини даних потрібна як мінімум 96-розрядна високошвидкісна лінія доступу до пам’яті від кожного процесора, що становить технологічну проблему.
Необхідність забезпечення обміну зі швидкістю 500 Мбайт/с і вище обме- жується фізичною відстанню від кожного процесора до кожного блока пам’яті. Зазвичай системи зі спільною пам’яттю виглядають досить компактно, розмі- щуючись в одному корпусі. Цей фактор є обмеженням під час збільшення зага- льної кількості процесорів через кількість блоків пам’яті, які можна розмістити в межах, заданих максимальною відстанню від блока пам’яті до процесора. Спільна пам’ять передбачає можливість усіх процесорів одночасно прочитати або записати різні дані з одного блока пам’яті, для цього кожний блок пам’яті повинен мати таку кількість точок входу, яка дорівнює кількості процесорів.
Як приклад можливого розв’язку цієї проблеми наведемо схему мережі типу «метелик» (рис. 2.2). Згідно із цією схемою вісім процесорних модулів можуть отримати доступ до восьми блоків пам’яті через систему комутаторів, однак у кожен конкретний момент до кожного блока пам’яті може мати доступ тільки один із процесорів, що в цілому знижує продуктивність системи.
Рис. 2.2. Комунікаційна мережа типу «метелик»
Деякі сучасні системи побудовано за кластерним принципом, за яким про- цесори й оперативну пам’ять поділяють на кілька груп – кластерів. Усередині кластера процесори мають швидкий доступ до оперативної пам’яті. Доступ процесорів одного кластера до оперативної пам’яті, розташованої в іншому кластері, так само можливий, але час доступу при цьому значно зростає.
Конфлікти, що неминуче виникають під час запису різними процесорами тих самих даних, мають фундаментальний характер і знижують продуктив- ність системи за рахунок утрат на синхронізацію, незалежно від конкретної апаратної реалізації системи. У такий спосіб сконструйована система зазви- чай не передбачає можливості суттєвого збільшення кількості процесорних вузлів і зумовлює високу вартість.