- •Розподілені системи
- •Історична довідка
- •Базові терміни та визначення
- •Телекомунікаційні мережі як елемент розподілених систем
- •Модель клієнт–сервер
- •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 основних етапів:
- •Комерційні системи обміну повідомленнями
-
Топології багатопроцесорних систем
Під топологією багатопроцесорної системи розуміємо спосіб з’єднання процесорних вузлів між собою каналами передачі даних. Зручно подати топо- логію системи у вигляді графу, вершини якого відповідають процесорним вуз- лам, а ребра – каналам зв’язку відповідно. Умовно топології можна поділити на фіксовані, реконфігуровані, з одного боку; на регулярні й нерегулярні – з другого. Серед регулярних широко використовують топології таких типів:
Топологія «лінійка» Топологія «кільце»
Топологія «решітка3х3» Топологія «тор 3х3»
Топологія «гіперкуб ступеня 4» Топологія «кліку»
Топологія «зірка» Топологія «трійкове дерево»
Властивості використовуваної топології визначають не лише ефективність виконання паралельної програми, але й можливість масштабування самої обчислювальної системи. Будь-яку кількість процесорів можна об’єднати в топології типів «лінійка», «кільце», «кліку», однак для побудови топологій
«решітка» або «тор» потрібно n1·n2 процесорів, а тому збільшення кількості процесорів можливе тільки квантами розміру n1 або n2. Для побудови тополо- гії «гіперкуб» потрібно n2 процесорів, це означає, що кожна наступна система має містити вдвічі більше процесорів, ніж попередня; така топологія вимагає для своєї реалізації наявності n каналів зв’язків на кожному процесорному вузлі, що також обмежує можливості збільшення кількості вузлів у системі.
Щоб підвищити ефективність виконання програм на обчислювальних системах, необхідно узгоджувати фізичну топологію системи й топологію задачі. Велика частина задач математичної фізики успішно розв’язується на системах, процесори яких об’єднані за топологією «решітка». Прямокутні просторові сітки, використовувані для числового інтегрування систем дифе- ренціальних рівнянь, які описують такі задачі, зручно поділяти на прямокутні частини, які безпосередньо відбиваються на решітці процесорів. Важливо, що від фізичної топології може суттєво залежати ефективність виконання конк- ретної програми. Перші багатопроцесорні системи, які набули поширення, мали обмежені можливості з погляду реконфігурування. Системи на основі трансп’ютерів дозволяли будувати топології процесорів «двовимірна решітка»,
«кільце», «циліндр» і «тор». Однак системами з топологією «тор» те, що мо- жна було побудувати на основі трансп’ютерів, можна назвати умовно: для реалізації топології «тор» потрібно саме чотири link, при цьому не залиша- ється link для приєднання системи до обчислювальної машини, яка керує об- числювальним процесом (рис. 2.14).
У разі такого поєднання процесорів порушується однорідність процесів передачі даних між ними під час обчислень. Побудувати таким чином топо- логію «гіперкуб» розміром більше 16 (24 = 16) процесорів, або топологію
«тривимірний куб», важко, не згрупувавши процесори у блоки; наприклад, поєднавши на основі спільної пам’яті у блоки по два процесори, отримаємо обчислювальні вузли з вісьмома link (рис. 2.15).
Рис. 2.14. Під’єднання процесорів, з’єднаних за топологією «тор», до керувальної машини
Рис. 2.15. Об’єднання процесорів у обчислювальні вузли
Гіперкуб і тривимірний куб містять топологію «решітка», у зв’язку з чим виникає запитання, якою має бути фізична топологія, щоб за наявності досить жорстких обмежень щодо кількості каналів отримати мінімальну відстань між найбільш віддаленими процесорами? Інакше кажучи, як можна мінімізувати діаметр графу процесорів, зберігаючи низку зв’язків, необхідних для ефектив- ного виконання програми?
Можливе часткове розв’язання цієї задачі – побудова топологій типу
«піраміда» (рис. 2.16, 2.17), які дають найкращий з можливих результат, але не є масштабованими.
Рис. 2.16. Приклад графу із 32 процесорами з діаметром і радіусом, що дорівнюють чотирьом
Рис. 2.17. Приклад графу «піраміда» із 64 процесорами з діаметром і радіу- сом,
що дорівнюють шести