Презентація на тему:
Операційні системи розподілених обчислювальних систем

Тема 9 :Операційні системи розподілених обчислювальних систем Викладач: д.т.н., проф. Саченко А.О. Високопродуктивні комп’ютерні системи Тернопіль 2006 Тернопільський Національний Економічний Університет Факультет комп'ютерних інформаційних технологій Кафедра Інформаційно обчислювальних систем та управління

Зміст лекції Два погляди на ОС. ОС, як менеджер ресурсів. Історія ОС. Розвиток від бібліотек процедур до сучасного стану. Серверні та кластерні ОС. Види операційних систем (мережеві ОС, розподілені ОС, ОС мультипроцесорних ЕОМ). Принципи побудови розподілених ОС (прозорість, гнучкість, надійність, ефективність, масштабованість). Операційні системи мультипроцесорних ЕОМ. Процеси і потоки. Види багатозадачності. Планування процесів та виконання процесів у середовищі ВКС. Розподілені файлові системи. Файлові сервери і сервери каталогів. Іменування ресурсів. Розподілена загальна пам'ять. Алгоритми реалізації DSM. Моделі консистентності. Система пакетного розподіленого виконання задач Condor.

1.Два погляди на ОС. ОС, як менеджер ресурсів. Два погляди: менеджер ресурсів; один шар в безлічі шарів абстрактних машин.

Представлення ОС як менеджера ресурсів

Представлення ОС як абстрактної машини Система команд

2.Історія ОС. Розвиток від бібліотек процедур до сучасного стану. Серверні та кластерні ОС. 1940-і і 1950-і "Персональні ЕОМ" - "пультовий режим" Бібліотека програм введення-виведення, службова програма. Середина 1950-х Пакетна обробка. Однопрограмний і мультипрограмний режими. Інструкція операторові -> паспорт завдання (проста мова управління завданнями). Вимоги до апаратури: * захист пам'яті; * переривання; * привілейований режим; * таймер.

Середина 1960-х Режим розділення часу. Термінали, квантування, свопінг, сторінкова і сегментна організація. 1970-і Багатопроцесорні ЕОМ, багатомашинні комплекси, мережі ЕОМ 1980-і Персональні ЕОМ 1990-і MPP, відкриті системи, Internet

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

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

Порівняння операційних систем

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

Гнучкість (не все ще ясно - потрібно буде міняти рішення). Використання монолітного ядра ОС або мікроядра. Надійність. Доступність, стійкість до помилок (fault tolerance). Секретність. Продуктивність. Гранульованість. Дрібнозернистий і грубозернистий паралелізм (fine-grained parallelism, coarse-grained parallelism). Стійкість до помилок вимагає додаткових накладних витрат.

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

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

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

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

Взаємодія процесів Якщо додаток реалізований у вигляді безлічі процесів (або ниток), то ці процеси (нитки) можуть взаємодіяти двома основними способами: за допомогою розділення пам'яті (оперативною або зовнішньою); за допомогою передачі повідомлень.

6.Планування процесів та виконання процесів у середовищі ВКС. Планування процесорів дуже сильно впливає на продуктивність мультипроцесорної системи. Можна виділити наступні головні причини деградації продуктивності: 1.Накладні витрати на перемикання процесора. Вони визначаються не тільки перемиканнями контекстів процесів, але і переміщеннями сторінок віртуальної пам'яті; 2.Перемикання на інший процес в той момент, коли поточний процес виконував критичну секцію, а інші процеси активно чекають входу в критичну секцію.

Застосовуються наступні стратегії боротьби з деградацією продуктивності. 1. Сумісне планування, при якому всі процеси одного додатку (неблоковані) одночасно вибираються на процесори і одночасно знімаються з них (для скорочення перемикань контексту). 2. Планування, при якому процеси, що знаходяться в критичній секції, не уриваються, а активно чекаючі входу в критичну секцію процеси не вибираються до тих пір, поки вхід в секцію не звільниться. 3. Процеси плануються на ті процесори, на яких вони виконувалися у момент їх зняття (для боротьби з псуванням кеша). При цьому може порушуватися балансування завантаження процесорів. 4. Планування з урахуванням "рад" програми (під час її виконання).

7.Розподілені файлові системи. Файлові сервери і сервери каталогів. Іменування ресурсів. Дворівнева схема іменування. Дві головні мети розподілених файлових систем. Мережева прозорість. Найважливіша мета - забезпечити ті ж самі можливості доступу до файлів, розподілених по мережі ЕОМ, які забезпечуються в системах розділення часу на централізованих ЕОМ. Висока доступність. Інша важлива мета - забезпечення високої доступності. Помилки систем або здійснення операцій копіювання і супроводу не повинні приводити до недоступності файлів.

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

Архітектура розподілених файлових систем Розподілена система зазвичай має два що істотно відрізняються компоненту - безпосередньо файловий сервіс і сервіс директорій.

Інтерфейс файлового сервера Для будь-якої файлової системи перше фундаментальне питання - що таке файл. У багатьох системах, таких як UNIX і MS-DOS, файл - послідовність байтів, що не інтерпретується. Так, як більшість розподілених систем базуються на використанні середовища UNIX і MS-DOS, то вони використовують перший варіант поняття файлу.

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

Прозорість іменування. Дві форми прозорості іменування розрізняють - прозорість розташування (/server/d1/f1) і прозорість міграції (коли зміна розташування файлу не вимагає зміни імені). Є три підходи до іменування: машина + шлях; монтування видалених файлових систем в локальну ієрархію файлів; єдиний простір імен, який виглядає однаково на всіх машинах.

Дворівневе іменування. Більшість систем використовують ту або іншу форму дворівневого іменування. Файли (і інші об'єкти) мають символічні імена для користувачів, але можуть також мати внутрішні двійкові імена для використання самою системою.

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

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

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

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

Когерентність кешів. Алгоритм з крізним записом. Необхідність перевірки, чи не застаріла інформація в кеші. Запис викликає комунікаційні витрати (MS-DOS). Алгоритм з відкладеним записом. Через регулярні проміжки часу всі модифіковані блоки пишуться у файл. Ефективність вища, але семантика незрозуміла користувачеві (UNIX). Алгоритм запису у файл при закритті файлу. Реалізує семантику сесій. Не набагато гірше за випадок, коли два процеси на одній ЕОМ відкривають файл, читають його, модифікують в своїй пам'яті і пишуть назад у файл. Алгоритм централізованого управління. Можна витримати семантикові UNIX, але не ефективно, ненадійно, і погано масштабується.

Sun Microsystems Network File System (NFS) Спочатку реалізована Sun Microsystem в 1985 році для використання на своїх робочих станцій на базі UNIX. В даний час підтримується також іншими фірмами для UNIX і інших ОС (включаючи MS-DOS). Цікаві наступні аспекти NFS - архітектура, протоколи і реалізація. Архітектура NFS дозволяє мати довільну безліч клієнтів і серверів на довільних ЕОМ локальної або широкомасштабної мережі.

8 Розподілена загальна пам'ять. Алгоритми реалізації DSM (з центральним сервером, міграційний алгоритм, алгоритм з розмноженням для читання, з повним розмноженням). Моделі консистентності. Традиційно розподілені обчислення базуються на моделі передачі повідомлень, в якій дані передаються від процесора до процесора у вигляді повідомлень. Видалений виклик процедур фактично є тією ж самою моделлю (або дуже близькою).

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

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

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

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

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

Моделі консистентності Строга консистентность; Послідовна консистентность; Причинна консистентность.

9.Система пакетного розподіленого виконання задач Condor. Кластерна система Condor (www.cs.wisc.edu/condor/downloads) була створена групою розробників Університета Wisconsin-Madison де і була більше 10 років тому розгорнена перша конфігурація. На сьогоднішній день в університеті є 350 настільних UNIX станцій, які включені в мережу Condor і надають доступ для роботи користувачам зі всього світу.

Система Condor - це ПЗ для підтримки середовища HTC(High Throughput Computing ), утвореного станціями на платформі UNIX і NT. Не дивлячись на те, що Condor може управляти спеціалізованими кластерами з робочих станцій, його ключова перевага - здатність розподіляти звичайні комп'ютерні ресурси, доступні в будь-якій лабораторії або офісі.

Апаратна структура Апаратна архітектура системи включає три типи комп'ютерів (мал. 1), об'єднаних в єдиний пул Condor: центральний менеджер (Central Manager), що виконують машини (Execute Machine), що запускають машини (Submit Machine).

Програмна архітектура Condor_master. Демон, контролюючий роботу всіх демонів Condor, запущених на кожній машині пулу і що виконує адміністративні команди системи. Даний демон повинен бути запушений на кожній машині з пулу. Condor_startd. Демон для представлення ресурсів в кулі. Працює на кожній виконуючій машині і у разі її готовності до виконання завдання запускає демон condor_starter. Condor_starter. Демон для запуску завдань і моніторингу процесу його виконання на конкретній машині. Після завершення завдання демон посилає повідомлення запускаючій машині і припиняє свою роботу. Condor_schedd. Демон управління ресурсами, необхідними для пулу Condor і повинен працювати на кожній запускаючій машині. При запуску завдання відбувається звернення до schedd, який розміщує завдання в черзі завдань. При збої демона schedd ніяка подальша робота не неможлива.

Condor_shadow. Демон, що працює на запускаючій машині і виконує функції менеджера ресурсів. Всі системні виклики з видалених машин пересилаються демонові condor_shadow, де виконуються, а результати відправляються назад видаленій машині і завданню. Condor_collector. Збір інформації про стан пулу Condor. Всі інші демони періодично посилають цьому демонові дані про свій стан. Condor_negotiator. Демон управління станом Condor. Періодично демон запускає цикл узгодження, протягом якого збираються дані про стан ресурсів, поточному положенні кожного демона condor_schedd з метою зміни пріоритетів і т.п. Condor_ckpt_server. Демон, що реалізовує функції сервера обробки контрольних крапок. У його завдання входить збереження поточного стану завдання.

Дякую за увагу!