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

 
















Дипломний проект

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


Список термінів, скорочень та позначень


КМ - компютерна мережа

КС - комп'ютерна система

МК - мікроконтролер

ОС - операційна система

ПЗ - програмне забезпечення

ШІМ - широтно-імпульсний модулятор

КМОН - комплементарний метал-оксидний-напівпровідник

ПЗУ - постійний запам'ятовувач

ЕСППЗУ - електронно програмовуваний постійний запам'ятовувач

ЕОМ - електронна обчислювальна машина

ВДТ - відео-дисплейний термінал


Вступ


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

У зв'язку з цим набула популярності концепція розподіленої обчислювальної інфраструктури під назвою GRID.

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

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

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

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

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


1. Огляд існуючих рішень та обгрунтування теми дипломного проекту


1.1 Розподілені обчислювальні мережі


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

Частковим випадком розподіленої обчислювальної мережі є GRID-система.

Під GRID-системою будемо розуміти [1] апаратно-програмну інфраструктуру, яка забезпечує надійний, стійкий, повсюдний і недорогий доступ до високопродуктивних комп'ютерних ресурсів.

В роботі [2] наведені критерії, на підставі яких розподілена система є GRID-системою. GRID-система - це така система, яка:

-Координує використання ресурсів за відсутності централізованого управління цими ресурсами;

-Використовує стандартні, відкриті, універсальні протоколи та інтерфейси;

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

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

Найбільш характерними властивостями такої апаратно-програмної інфраструктури є [3-6]:

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

-Гетерогенність середовища; до її складу можуть входити комп'ютери різної потужності, що працюють під управлінням різних операційних систем і зібрані на різній елементній базі;

Просторовий розподіл інформаційно-обчислювального ресурсу;

Об'єднання ресурсів, які не можуть керуватися централізовано (у випадку, якщо вони не належать одній організації);

Використання стандартних, відкритих, загальнодоступних протоколів та інтерфейсів.

Забезпечення інформаційної безпеки.

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

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

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

-Організація доступу користувачів до ресурсів;

-Забезпечення прозорості;

Відкритість;

Масштабованість.

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

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

-Прозорість доступу: до локальних або віддаленим об'єктів можна звертатися за допомогою однакових операцій;

-Прозорість місцезнаходження: об'єкти повинні бути доступні без необхідності знати їх фізичне місце розташування;

Прозорість одночасності доступу: кілька користувачів повинні мати можливість одночасного доступу до даних, без небажаних наслідків;

Прозорість копіювання: повинна існувати можливість копіювати дані з файлів або з інших об'єктів з метою підвищення ефективності або забезпечення доступності непомітно для користувачів;

Прозорість при несправності: користувачі або прикладні програми повинні мати можливість завершити свої завдання, навіть у випадку несправностей апаратної або програмної частини;

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

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

Масштабованість GRID-систем може вимірюватися за трьома різними показниками [13]:

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

-Система може масштабуватися географічно, тобто користувачі і ресурси можуть бути рознесені в просторі;

Система може бути масштабованої в адміністративному сенсі, тобто бути проста в управлінні при роботі в безлічі адміністративно незалежних організацій.

Спосіб організації програмного забезпечення GRID заснований на відкритій архітектурі служб OGSA [8], у відповідністю з якою GRID кваліфікується як програмна система, що складається із розподілених компонентів - служб, що взаємодіють між собою за допомогою стандартних, відкритих і універсальних протоколів і інтерфейсів [9]. Маючи на увазі головним чином GRID обчислювального типу, можна розглядати його функціонування як процес обслуговування стандартизованих запитів на виконання обчислень, оформлених у вигляді завдань для загальнопоширених операційних систем, причому виконання цих завдань відбувається на ресурсах, які вибираються із загального пулу. Перелічимо основні етапи обробки завдання [7]:

-Планування ресурсів. Спеціальна компонента програмного забезпечення - планувальник виділяє із загального пулу ресурси, на яких завдання буде виконуватися.

-Доставка виконуваних файлів і вхідних файлів на виконавчі ресурси.

Виконання завдання.

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

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

Оскільки GRID - розподілене середовище, то, як показала практика, необхідні [7] спеціальні служби, які виконують:

-Моніторинг і протоколювання процесу обробки запиту, що дозволяє в кожний момент отримувати інформацію про місцезнаходження та стан завдання, а також керувати його обробкою (видалення, модифікація);

-Забезпечення надійності - перезапуск завдання при збоях програмних або апаратних засобів на ресурсах і телекомунікації;

Моніторинг і облік споживання ресурсів, на основі чого проводиться планування та діагностика збоїв устаткування.


.2 Класифікація GRID систем


Залежно від способу взаємодії елементів GRID-систем і передачі даних між ними, можна виділити такі основні види організації структури GRID-систем:

Плоска;

-Стільникова (стільникова плоска або стільникова ієрархічна);

Ієрархічна.

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

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

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

За типом ресурсів, що надаються, та видам прикладних задач, під рішення яких система оптимізована, GRID-системи поділяються наступним чином:

)Обчислювальні GRID-системи (Computational Grid) [14] - це тип систем, в яких основним комп'ютерним ресурсом є продуктивність процесора. Серед них можна виділити:

-«розподілені супер-обчислювальні системи» (Distributed Supercomputing);

-«високопродуктивні системи» (High Throughput), які функціонують в паралельному режимі на декількох вузлах.

)Інформаційні GRID-системи (Data Grid) - це тип систем, в яких основним комп'ютерним ресурсом є обсяг пам'яті даних. Ці системи розглядаються як величезні сховища даних, які зазвичай тісно взаємопов'язані з обчислювальними GRID-системами.

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

)Обслуговуючі GRID-системи (Service Grid) - до даної категорії відносяться системи, що мають сервіси, які не можуть бути забезпечені окремими робочими станціями, а саме:

-Динамічне агрегування даних і надання нових сервісів;

-Надання віртуального робочого простору для користувачів та програм;

Надання інфраструктури для мультимедійних додатків реального часу.

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


.3 Основні способи планування в GRID-системах


В даний час існує три основних способи планування в Grid системі: централізований, децентралізований і ієрархічний [15].

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

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

При ієрархічному способі процес планування завдань розподілений на двох рівнях: глобальному і локальному. На глобальному рівні управління завдань здійснює метапланувальник GRID, а на локальному - менеджер ресурсів. На відміну від централізованих метапланувальники GRID-системи зазвичай не можуть безпосередньо управляти ресурсами мережі, але працюють як брокери чи агенти [16]. Інформація про стан доступних ресурсів дуже важлива для метапланувальника GRID-системи для того, щоб виконати ефективне планування, особливо з урахуванням неоднорідної і динамічної природи GRID-мережі. Роль інформаційної служби GRID-системи (Grid information service (GIS)) - забезпечити такою інформацією планувальників GRID. GIS відповідальна за збір і прогноз інформації про стан ресурсу, такої як продуктивність процесора (процесорів) вузлів, розмір пам'яті, пропускна здатність мережі, готовність програмного забезпечення та завантаження вузла в певний період. GIS відповідає на запити для отримання інформації про ресурс або передає інформацію користувачам. Система моніторингу та контролю Globus (The Globus Monitoring and Discovery System (MDS)) [6] - приклад GIS.

Крім інформації про ресурс від GIS, властивості задач (наприклад, приблизна кількість команд, вимоги до пам'яті та зберігання, залежність підзадач в завданні і обсяги комунікації) і продуктивність ресурсу для різних видів задач також необхідні для виконання ефективного планування. Отримання зазначених властивостей може бути забезпечено компонентою профілювання програми (Application profiling (AP)), а вимір продуктивності ресурсу для даного типу задачі - компонентою тестування (analogical benchmarking (AB)). На основі інформації, отриманої від AP і AB, а також на основі своєї моделі продуктивності проводиться оцінка вартості планування вузлів-кандидатів на виконання задачі, з яких планувальник вибирає оптимальний відповідно до цільової функції.

Модуль запуску і контролю (Launching and Monitoring LM) (також відомий як "компонувальник") здійснює передачу задачі на обрані ресурси, пересилаючи вхідні дані і виконувані файли, а в разі потреби і контролює виконання програм. LM Globus GRAM (Grid Resource Allocation and Management) - приклад такого модуля.

Локальний менеджер ресурсів головним чином відповідає за виконання зовнішніх (отриманих від метапланувальника) і локальних завдань, а також передає повідомлення для GIS з інформацією про стан ресурсів. У межах домену один або безліч місцевих планувальників працюють з конкретною локальної політикою управління ресурсами. Приклади таких локальних планувальників включають openpbs і Condor. Для збору інформації про локальний ресурс LRM використовують такі інструментальні засоби, як Network Weather Service, Hawkeye і Ganglia [17].

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

В GRID-системах планувальник задач реалізований як складова частина системи керування загрузкою (WMS - Workload Management System).

Завданням підсистеми управління завантаженням (WMS) є прийняття запитів на запуск завдань, пошук відповідних ресурсів і контроль їх виконання.. До складу WMS входять:

-Менеджер загрузки;

-Планувальник / брокер ресурсів;

Адаптер завдань;

Модуль, відповідальний за виконання фактичних операцій з управління завданнями;

Монітор log-файлів WMS.

WMS розподіляє завдання по множині обчислювальних елементів. Обчислювальний елемент може працювати як у відповідністю з моделлю «нетерплячого планування» (push-модель), коли менеджер загрузки самостійно приймає рішення про посилку задачі на обчислювальний елемент, так і в режимі «лінивого планування» (pull-модель), коли обчислювальний елемент запитує завдання у WMS. Обидві стратегії планування мають свої переваги і недоліки. Вибір тієї чи іншої стратегії або їх комбінації залежить від призначення і характеристик роботи (зокрема, інтенсивності запуску задач, числа ресурсних центрів тощо) GRID-системи.

Більшість існуючих розробок в області диспетчеризації завдань в GRID-системах призначені для обслуговування кластеризованих ресурсів, у тому числі система WMS найбільшого на сьогоднішній день GRID проекту EGEE.

Як показано в [7] брокер системи WMS реалізує централізовану схему планування, що працює в двох режимах розподілу завдань: жадного і лінивого (лінивий режим був вперше реалізований в проекті Alien [18]).

Інформаційна база жодного режиму, побудована на інформаційній службі MDS системи Globus Toolkit, недостатньо повна: вона не містить даних, що описують процесорні вузли, так що цей режим може використовуватися тільки в GRID з однорідними ресурсами. Співставлення характеристик ресурсів та завдань в лінивому режимі виконується на основі методу matchmaking [19] і не має такого недоліку.

Система управління завданнями ARC [20] проекту nordugrid представляє інтерес як приклад децентралізованої архітектури планування. У деяких системах знаходять застосування два нових механізму: резервування та міграції. Сценарій Moab Grid Scheduler виглядає наступним чином:

-Завдання GRID надходять в глобальну чергу;

-Планувальник посилає запити в кластери і отримує від них час можливих алокацій;

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

Moab, також як і CSF (Community Scheduler Framework), який також підтримує резервування в службі планування, не дає повного рішення, припускаючи, що програмне забезпечення на кластерах має засоби для прийняття рішень про те, коли можуть бути відведені ресурси для резервування. Системи gridway і gridlab Resource Management System (GRMS) використовують механізм перерозподілу завдань - міграцію. У gridway після того як глобальне завдання надіслано в кластер спеціальна служба здійснює його моніторинг. У випадку, якщо завдання не запущено, в локальному менеджері ресурсів за певний інтервал часу відбувається перепланування даного глобального завдання, і воно переміщається на інші ресурси.

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

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

В [22] обґрунтовується необхідність розширення функціональності сучасних систем планування функціями попереднього резервування ресурсів і складання розкладів запуску завдань. Автори описують відмінність між системами планування двох типів: традиційними - Queuing systems і системами, заснованими на розкладах - Planning systems. У той час як перші розподіляють завдання, виходячи з поточного стану ресурсів, другі ґрунтуються на повноцінному плані на майбутнє. На думку авторів такий підхід, що реалізований у системі CCS [23], сприяє застосуванню апарату попереднього резервування і відкриває перспективу для вирішення завдання управління паралельними задачами.

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


1.4 Огляд існуючих систем планування


.4.1 Планувальник Maui

Початкове призначення системи планування Maui [26] - оцінка ефективності завантаження ресурсів: отримуючи на вхід чергу завдань і використовуючи поточні настройки кластерного планувальника, вона видає почасовий розподіл завдань по ресурсах. Особливістю даного планувальника є використання алгоритмів зворотного заповнення (backfill) [27,28] і справедливого розподілу ресурсів (fairshare), які підвищують ефективність системи і зменшують час очікування в черзі. Обидва ці механізми є додатковими опціями, які можна використовувати.

Алгоритм зворотного заповнення - найкращий на сьогодні алгоритм для планування багатопроцесорних завдань [7]. Перевагами [28] даного алгоритму є:

-В умовах роботи у пріоритетній системі дозволяє уникнути зависання завдання, гарантуючи його запуск;

-Ефективно завантажує ресурси, дозволяючи уникнути їх фрагментації;

Має прийнятні часові характеристики при роботі на великій кількості обчислювальних вузлів;

Дозволяє працювати на безлічі гетерогенних ресурсів.

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

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

Наявність системи автоматичного визначення пріоритетів завдань дозволяє давати ключовим користувачам перевагу при розподілі ресурсів. Maui - один з перших планувальників, в якому з'явився розширений менеджер статистики [30], що містить: повну історичну та поточну інформацію про завдання, чергах, планувальнику, стан системи і т.п. Ще одна властивість планувальника в тому, що Maiu має командний інтерфейс для зовнішнього або, так званого, адміністративного резервування.

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

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


.4.2 Планувальник системи Ursalaистема Ursala [7] використовує інтерфейс попереднього резервування, що гарантує виділення ресурсів і запуск завдання в замовлений

Час, а також дистанційний інтерфейс з локальним планувальником, що дозволяє визначити можливість виконання завдання на відповідному обчислювальному вузлі [22]. Система також дозволяє планувати багатопроцесорні завдання, але для цього користувач повинен явно вказати ресурси, на яких він хоче розмістити своє завдання. З зазначених обчислювальних вузлів в систему надходять списки часових інтервалів, в які завдання може бути запущено, після чого планувальник визначає кращий час запуску завдання на цих ресурсах. Таким чином, основний недолік цієї системи полягає в тому, що вона здійснює планування вимагаючи від користувача конкретизації ресурсів для запуску його завдання.


.4.3 Брокер системи WMS

Брокер системи WMS (Workload Management System) [31] реалізує централізовану схему планування. При цьому розрізняють два режими розподілу завдань: жадібний і ледачий, так само можливі комбіновані варіанти цих двох режимів.

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

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

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


.4.4 Планувальник CSF

Планувальник CSF (Community Scheduler Framework) [32] відноситься до централізованих планувальників через наявність глобальної черги завдань. Основний принцип планування, на якому заснований цей метод, - це попереднє резервування ресурсів. Вхідну черги завдань для планувальника формує одна з утиліт, що задає їм пріоритет відповідно до обраної політики розподілу. Планувальник має служби нотифікації, завдяки чому стежить за звільненням ресурсів і може здійснювати миттєве занурення. Планувальник CSF є відкритою реалізацією і включений в globustoolkit.


.4.5 Система керування завданнями ARC

Система керування завданнями ARC (Advanced Resource Connector) [20] використовується в проекті nordugrid. АРК реалізує фундаментальні служби Grid, такі як інформаційна служба, пошук і зіставлення ресурсів, спостереження за ресурсами, керування ресурсами. Система не використовує більшість служб, що входять до globustoolkit. Всі реалізовані нею служби надбудовуються над бібліотеками globustoolkit, проте працюють під захистом служби безпеки GSI [33].

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


.4.6 Планувальник системи PAUA

Grid складається з ресурсів, які розрізнені по всьому світу. При цьому вони можуть бути як настільними, так і суперкомпютерами. Для отримання доступу до них необхідно створити запит до менеджера ресурсів.

Планувальник, використовуваний в системі PAUA, званий sitesheduler [34], так представляє розрізнені ресурси, щоб вони були доступні планувальникам. Це передбачає, що жоден з планувальників не може провести планування, не пройшовши через sitesheduler. Основними завданнями планувальника сайту є верифікація прав доступу до завдань Grid та виділення ресурсів для твору обчислень користувача завдань. Даний планувальник має такі особливості:

-Наявність служб, що кешують завдання і виконувані файли так, що планувальник може працювати, як проксі-сервіс;

-Наявність служби моніторингу ресурсів і прогноз виконання алокації;

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

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


.4.7 Брокер GRB[35] - брокер ресурсів Grid, який служить для контролю і керування завданнями користувачів. GRB містить такі компоненти [42]:

-Resource Broker Master (RBM) - це основний процес, який приймає від користувачів всі запити;

-Resource Broker Assistant (RBA) - це процес, породжуваний Resource Broker Master для обробки певного запиту від користувача, який здійснює функцію розподілу завдань по ресурсах;

-Job Registry (JR) - база даних, в якій зберігається вся інформація, потрібна GRB;

-Job Submission Service (JSS) - служба запуску задач на ресурсах та їх моніторингу;

-Grid Security Infrastructure (GSI) - інфраструктура безпеки;

User Interface (UI) - інтерфейс користувача, що забезпечує взаємодію користувача з RBA.

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

Для виконання роботи користувача обробник запиту має взаємодіяти зі службою JSS, яка запускає і скасовує виконання завдання на ресурсі. При цьому взаємодія RBM та JSS засновано на тому, що RBM проводить опитування, чи не пришло від JSS повідомлення.M - є основною ланкою в системі. Він приймає як запити користувачів, так і повідомлення про завершення та скасування роботи.

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


.4.8 Планувальник Moab Workload Manager

Робота Moab Workload Manager базується на декількох алгоритмах створення черги задач та вибору обчислювального вузла для кожної задачі.

Сценарій Moab Grid Scheduler виглядає наступним чином:

-Завдання GRID надходять в глобальну чергу;

-Планувальник посилає запити в кластери і отримує від них час можливих алокацій;

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

Moab, також як і CSF (Community Scheduler Framework), який також підтримує резервування в службі планування, не дає повного рішення, припускаючи, що програмне забезпечення на кластерах має засоби для прийняття рішень про те, коли можуть бути відведені ресурси для резервування.


2. Алгоритм динамічного планування задач


Незважаючи на широке визнання алгоритм планувальника Moab Workload Manager має певні недоліки, серед яких пошук ресурсу з початку списку та ігнорування такого параметру як кількість даних для задачі.

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


.1 Алгоритм планувальника Moab Workload Manager


Moab Workload Manager є високорозвиненою системою планування та управління задачами, що призначена для кластерів, grid та систем on-demand/utility обчислень. На верхньому рівні, Moab застосовує задані політики і масову оптимізацію, щоб організувати виконання задач та сервісів задля оптимального використання можливостей мережі, обчислювальних та зберігаючих ресурсів. Moab дозволяє реалізувати справжні адаптивні обчислення завдяки тому, що обчислювальні ресурси можуть бути пристосовані до потреб, які постійно змінюються, то завдяки тому, що система може автоматично виправляти або видаляти несправні вузли.підвищує доступність системних ресурсів, має широкі можливості для діагностики ресурсів, забезпечує потужні функції qos / SLA, а також надає якісну візуалізацію продуктивності ресурсів через розширену статистику, звіти і графіки.

Moab працює практично з усіма основними утилітами керування та моніторингу ресурсів. Від апаратних систем моніторингу (таких як IPMI) до систем забезпечення і зберігання, Moab використовує статистику та власний досвід, щоб ці системи працювали найкраще.

Moab використовує свою глобальну інформацію для координації діяльності ресурсів та сервісів задля підвищення загальної продуктивності.

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

Інформація про завдання надається планувальнику одним із менеджерів ресурсів, таких як loadleveler, PBS, Wiki, або LSF. Атрибути завдання включають в себе: власник, стан завдання, кількість і тип ресурсів, необхідних для завдання та межі часу, як довго ресурси будуть зайняті завданням. Завдання складається з однієї або кількох задач, кожна з яких потребує задану кількість ресурсів заданого типу. Наприклад, завдання може складатися з двох груп задач, перша з яких включає одну основну задачу (master) і потребує один вузол IBM SP з не менш як 512 МБ оперативної пам'яті, а друга містить набір залежних задач (slave) та потребує 24 вузла IBM SP з не менш як 128 МБ оперативної пам'яті. Кожна група складається з однієї або кількох задачі, де задача визначається як мінімальна самостійна одиницю ресурсів. За замовчуванням, кожна задача еквівалентна одному процесору. У середовищі SMP, тим не менш, користувачі можуть зв'язати один або кілька процесорів разом з певним обсягом пам'яті та інших ресурсів для однієї задачі.

Стани завдання:EFFERED - завдання, яке було відкладено планувальником Moab через неможливість виконати планування завдання в поточних умовах. Відкладені завдання затримуються на час DEFERTIME перед тим як знову розмістити їх у чергу завдань. Цей процес повторюється DEFERCOUNT разів, перш ніж завдання відправляється до відкинутих (HOLD) завдань.- завдання знаходиться в режимі очікування і не має права працювати у зв'язку з вказівкою користувача, системного адміністратора, або у випадку, коли завдання відкинуто.- завдання в даний час у черзі і має право виконуватися, але не виконується.- завдання, яке надіслано до віддаленого вузла, але яке ще не почалося виконуватися.- завдання було перенесено на інший планувальник, але ще не почалося виконуватися.

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

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

Типовий алгоритм обробки завдань в Moab:

)Визначення списку доступних завдань

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

)Пріоритетизація завдань

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

)Забезпечення виконання заданої політики регулювання

Політика регулювання вказує, скільки завдань, вузлів, процесорів тощо дозволено використовувати в одиницю часу. Завдання, що порушують задану політику не використовуються для планування.

)Визначити доступність ресурсів

Для кожного завдання, Moab намагається знайти необхідні ресурси, які потрібні щоб виконати необхідні обчислення. Щоб встановити відповідність між задачами та ресурсами, вузол повинен володіти всіма атрибутами, які визначені в завданні, та відповідати обмеженню, заданому константою taskspernode (завдань на вузол). За замовчуванням taskspernode = 1. Зазвичай, Moab визначає що вузол має достатньо ресурсів, якщо ресурси не використовуються, та не призначені для виконання іншого завдання.

)Призначити ресурси завданням

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

)Розподіл задач по вузлам

Після обрання ресурсів, Moab призначає завдання на реальні ресурси. Розподіл відбувається, як правило на основі простих алгоритмів розподілу завдань, таких як циклічний, але може бути також запрограмований на мові паралельного програмування (наприклад, MPI або PVM) задля мінімізації накладних витрат на міжпроцесну взаємодію.

) Запуск роботи

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

Як ми бачимо із пунктів 2 та 5, значною частиною алгоритму планування є спосіб пріоритетизації задач та політика призначення ресурсів.

Пріоритетизація відбувається шляхом створення черги задач за певним принципом. Moab підтримує декілька таких принципів. Ми розглянемо декілька базових:

)Створення черги за принципом FIFO

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

)Сортування завдань за вагою обчислень за зростанням

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

)Сортування завдань за вагою обчислень за збиванням

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

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

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

)FIRSTAVAILABLE - вузли обираються в порядку, в якому вони присутні в менеджері ресурсів. Це дуже простий та найшвидший алгоритм.

)LASTAVAILABLE - вузли обираються в зворотному порядку, в якому вони присутні в менеджері ресурсів.

)PRIORITY - вузли обираються за заздалегідь заданим пріоритетом.

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

)FASTEST - вузли обираються за їх потужністю. Цей режим дозволяє виконувати завдання якнайшвидше.

Опис алгоритму:

)Визначення списку доступних завдань;

)Пріоритетизація завдань та створення черги завдань згідно до обраного способу пріоритетизації завдань;

3)Створення списку ресурсів згідно до обраного режиму призначення ресурсів;

)Вибір першого завдання з черги завдань;

)Вибір першого вузла зі списку ресурсів;

)Призначення обраного вузла обраному завданню;

)Пересилка завдання на обраний вузол;

)Якщо список доступних завдань не пустий - переходимо до п. 4;

2.2 Модифікований алгоритм планувальника Moab Workload Manager


При плануванні кожної наступної задачі Moab Workload Manager починає перегляд списку ресурсів з початку. Це призводить до того, що призначення ресурсів виконується нерівномірно: вузли в початку списку завжди будуть більш завантаженими, ніж у кінці. Також це призводить до зменшення швидкості планування через те, що при послідовному призначенні N задач на і-му шагу перші і-1 вузли буде вже гарантовано призначено, але планувальник все одно буде переглядати їх.

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

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

На рисунку 2.1 ми бачимо, що планувальник призначив задачу 1 та задачу 2 на перший та другий вузол відповідно. Задача 3 та задача 4 призначені на третій та четвертий вузол відповідно. Оскільки задача 1 та 2 перші в черзі планувальника, то їх передача почнеться раніше та вони займуть обидві лінії звязку планувальника. Тоді задачі 3 та 4, які мають менший обсяг даних


Рисунок 2.1 Неоптимальне використання ліній звязку


Третій та четвертий вузол відповідно. Оскільки задача 1 та 2 перші в черзі планувальника, то їх передача почнеться раніше та вони займуть обидві лінії звязку планувальника. Тоді задачі 3 та 4, які мають менший обсяг даних для передачі не будуть відправлені поки триває передача задач 1 та 2, які мають більший обсяг даних. В даному випадку, задачі 3 та 4 будуть чекати час 50/S, де S - швидкість передачі даних.

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

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

Третя модифікація тісно повязана з другою: призначати вузли, швидкість зєднання з якими нижча, задачам з меншою кількістю даних. Це також дозволить зменшити час, який задачі проводять в черзі на відправлення до вузлів. Але, оскільки в деяких режимах роботи планувальника (FIRSTAVAILABLE та LASTAVAILABLE) ця модифікація призведе до повної зміни алгоритму вибору ресурсу, то для цих режимів вона не використовується. Для таких режимів як CPULOAD, PRIORITY, MINRESOURCE та FASTEST частіш за все для однієї задачі існує декілька варіантів призначення, які є рівноправними з точки зору обраного режиму вибору ресурсу. Наприклад, в режимі FASTEST може бути декілька вузлів з приблизно однаковою швидкодією. Цю модифікацію можна використовувати для вибору одного з них.

Підсумуємо все вищесказане. Модифікація базового алгоритму полягає в наступних трьох пунктах:

-Циклічний перегляд списку вузлів;

-Передача спочатку задач з меншою кількістю даних;

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

Перевагами є:

-Більш рівномірна загрузка;

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

Серед недоліків можна виділити:

-Збільшення часу планування;

-Необхідність в зборі статистики швидкості підключення вузлів.

Опис модифікованого алгоритму:

)Визначення списку доступних завдань;

)Пріоритетизація завдань та створення черги завдань згідно до обраного способу пріоритетизації завдань;

3)Створення списку ресурсів згідно до обраного режиму призначення ресурсів;

)Вибір групи завдань для планування з однаковим пріоритетом із черги завдань;

)Сортування групи завдань за обємом даних для обробки;

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

)Сортування групи вузлів за швидкістю зєднання з планувальником;

)Вибір завдання з найменшим обємом даних із групи;

)Вибір вузла з найкращою швидкістю зєднання з планувальником;

)Призначення обраного вузла обраному завданню;

)Якщо в групі завдань ще є завдання, то переходимо до п. 6;

)Якщо список доступних завдань не пустий - переходимо до п. 5;

)Сортування спланованих завдань за обємом даних;

)Розсилка завдань на призначені вузли.


3. Розробка системи моделювання роботи GRID


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

В основу системи моделювання покладені принципи, за якими працює планувальник Moab Workload Manager.

Система містить реалізацію базового, модифікованого алгоритмів та має наступні функції:

-Створення та редагування структури GRID-системи;

-Читання та запис в файл структури GRID-системи;

-Генерація завдань для виконання;

-Вибір параметрів моделювання;

Планування завдань;

Моделювання роботи GRID-системи;

Збір та відображення статистики.

В системі реалізовані наступні режими пріоритетизації завдань:

Створення черги за принципом FIFO;

-Сортування завдань за вагою обчислень за зростанням;

Сортування завдань за вагою обчислень за збиванням.

Можливі режими призначення ресурсів:

-FIRSTAVAILABLE - за порядком присутності в списку ресурсів;

-FASTEST - за потужністю вузлів.

Інтерфейс системи моделювання зображено на рисунку 3.1.


Рисунок 3.1 Зовнішній вигляд системи моделювання


Система реалізована на мові програмування C# та має модульну структуру. Звязок між модулями зображено на рисунку 3.2.

Проект складається з трьох модулів.

Модуль Core - ядро системи. Воно представляє собою програмну модель GRID, містить реалізацію базового та модифікованого алгоритмів і безпосередньо відповідає за моделювання роботи GRID.


Рисунок 3.2 Звязок між модулями програми


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

Модуль Utils містить утілити для роботи з файловою системою. Відповідає за збереження структури GRID у файл та читання з нього.


.1 Модуль Core


За структуру GRID системи відповідають класи Node, Line та класи, що є наслідувані від них. Node представляє собою обчислювальний вузол, а Line - лінію звязку. Ієрархію класу Node можна побачити на рисунку 3.3. Ієрархію класу Line можна побачити на рисунку 3.4. Бачимо, що обидва цих класи реалізують інтерфейс itimeobserver, який містить метод handletimerevent(). Цей інтерфейс необхідний для реалізації шаблону проектування «спостерігач».


Рисунок 3.3 Ієрархія класу Node


Рисунок 3.4 Ієрархія класу Line


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

Діаграма класів для таймера представлена на рисунку 3.5.


Рисунок 3.5 Діаграма класів таймера


Задачі для виконання реалізовані в класі Task. Черга завдань - в абстрактному класі taskqueue та його наслідниках. Кожен наслідник реалізує певний режим пріоритетизації завдань. Доступні режими перераховані в структурі queuediscipline:

Public enum queuediscipline

{

FIFO,

LONGTASKFIRST,

}

Ієрархія класу taskqueue наведено на рисунку 3.6.


Рисунок 3.6 Ієрархія класу taskqueue


Клас fifotaskqueue реалізує чергу за принципом FIFO («перший зайшов - перший вийшов»). Клас ltftaskqueue - чергу, відсортовану за вагою обчислень за збиванням. Клас stftaskqueue - чергу, відсортовану за вагою обчислень за зростанням. Структура GRID-системи міститься у класі Grid у вигляді матриці ліній звязку modelline та списку вузлів modelnode. Кожна [i,j]-та лінія звязку в матриці зєднує i-й j-й обчислювальний вузол. Діаграма класу Grid представлена на рисунку 3.7.


Рисунок 3.7 Діаграма класу Grid


Алгоритми планування реалізовані в абстрактному класі Scheduller та його наслідниках. Кожен з наслідників реалізує певний режим призначення ресурсів. Доступні режими перераховані в структурі schedullermode:

Public enum schedullermode

{

FIRSTAVAILABLE,

FASTEST

}

Ієрархія класу Scheduller наведено на рисунку 3.8.


Рисунок 3.8 Ієрархія класу Scheduller


Фасадом всього модулю Core є клас modelcontroller, завдяки якому спрощується взаємодія ядра з іншими модулями. Цей клас містить в собі посилання на таймер, генератор задач, структуру Grid, класи планувальників, черг задач та інше.

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


3.2 Модуль GUI


Інтерфейс програми створено по типу стандартних вікон Windows. Програма вміщує в собі 8 діалогових вікон серед яких:

-Головне вікно (рисунок 3.9)

-Вікно інформації про програму (рисунок 3.10)

Вікно параметрів лінії звязку (рисунок 3.11)

Вікно вибору параметрів моделювання (рисунок 3.12)

Вікно параметрів вузла (рисунок 3.13)

Вікно виводу результатів моделювання (рисунок 3.14)

Вікно генерації задач (рисунок 3.15)

Вікно виводу графіків за обємом даних та часом підрахунків (рисунок 3.16)


Рисунок 3.9 mainform.cs


Рисунок 3.10 aboutbox.cs


Рисунок 3.11 linedialog.cs


Рисунок 3.12 modelingsettings.cs


Рисунок 3.13 nodedialog.cs


Рисунок 3.14 resultform.cs


Рисунок 3.15 taskgendialog.cs


Рисунок 3.16 tasksform.cs


Усі форми програми використовують стандартні С# функції для роботи з візуалізацією даних. Для побудови діаграм використовується стандартна бібліотека System.Drawing.


.3 Модуль Utils


Розроблена програма має функцію збереження та завантаження розробленої GRID - топології. Модуль Utils включає в собі клас fileutils з двома функціями savefile та loadfile:

Static class fileutils

{static void savefile(String file, serializablecontainer container)

{bf = new binaryformatter();fs = new filestream(file, filemode.Create, fileaccess.Write);.Serialize(fs, container);.Close();

}static serializablecontainer loadfile(String file)

{bf = new binaryformatter();fs = new filestream(file, filemode.Open, fileaccess.Read);

Return (serializablecontainer) bf.Deserialize(fs);

}

}

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


4. Моделювання роботи розподіленої обчислювальної мережі


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


.1 Створення черги за принципом FIFO FIRSTAVAILABLE


Режим пріоритетизації: створення черги за принципом FIFO. Режим призначення ресурсів: FIRSTAVAILABLE.

На рисунку 4.1 зображена порівняльна гістограма часу виконання задач в GRID в залежності від кількості задач для планування.


Рисунок 4.1 Час виконання задач


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


Таблиця 4.1 Приріст продуктивності GRID системи

Кількість задач1002003004005006007008009001000Приріст продуктивності, %3,04,12,013,623,423,017,614,915,07,5

Середній приріст продуктивності - 12,4%.

На рисунку 4.2 зображена порівняльна гістограма завантаженості вузлів системи.


Рисунок 4.2 Завантаженість вузлів GRID


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

На рисунку 4.3 зображена порівняльна гістограма часу перебування задач в черзі планувальника в залежності від кількості задач для планування.

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


Рисунок 4.3 Час перебування задач в черзі планувальника


.2 Сортування завдань за вагою обчислень за зростанням FIRSTAVAILABLE


Режим пріоритетизації: сортування завдань за вагою обчислень за зростанням. Режим призначення ресурсів: FIRSTAVAILABLE.

На рисунку 4.4 зображена порівняльна гістограма часу виконання задач в GRID в залежності від кількості задач для планування.


Рисунок 4.4 Час виконання задач


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

Приріст продуктивності можна побачити в таблиці 4.2.


Таблиця 4.2 Приріст продуктивності GRID системи

Кількість задач1002003004005006007008009001000Приріст продуктивності, %5,63,92,19,831,424,213,623,419,015,8

Середній приріст продуктивності - 14,9%.

На рисунку 4.5 зображена порівняльна гістограма завантаженості вузлів системи.


Рисунок 4.5 Завантаженість вузлів GRID


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


Рисунок 4.6 Час перебування задач в черзі планувальника


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


.3 Сортування завдань за вагою обчислень за спаданням FIRSTAVAILABLE


Режим пріоритетизації: сортування завдань за вагою обчислень за спаданням. Режим призначення ресурсів: FIRSTAVAILABLE.

На рисунку 4.7 зображена порівняльна гістограма часу виконання задач в GRID в залежності від кількості задач для планування.


Рисунок 4.7 Час виконання задач


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

Приріст продуктивності можна побачити в таблиці 4.3.


Таблиця 4.3 Приріст продуктивності GRID системи

Кількість задач1002003004005006007008009001000Приріст продуктивності, %3,14,15,24,113,311,09,411,13,51,0

Середній приріст продуктивності - 6,6%.

На рисунку 4.8 зображена порівняльна гістограма завантаженості вузлів системи.


Рисунок 4.8 Завантаженість вузлів GRID


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


Рисунок 4.9 Час перебування задач в черзі планувальника

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


4.4 Створення черги за принципом FIFO FASTEST


Режим пріоритетизації: створення черги за принципом FIFO. Режим призначення ресурсів: FASTEST.

На рисунку 4.10 зображена порівняльна гістограма часу виконання задач в GRID в залежності від кількості задач для планування.


Рисунок 4.10 Час виконання задач


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

Приріст продуктивності можна побачити в таблиці 4.4.


Таблиця 4.4 Приріст продуктивності GRID системи

Кількість задач1002003004005006007008009001000Приріст продуктивності, %13,110,827,720,835,219,418,125,126,323,4

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

На рисунку 4.11 зображена порівняльна гістограма завантаженості вузлів системи.


Рисунок 4.11 Завантаженість вузлів GRID


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

На рисунку 4.12 зображена порівняльна гістограма часу перебування задач в черзі планувальника в залежності від кількості задач для планування.


Рисунок 4.12 Час перебування задач в черзі планувальника


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

4.5 Сортування завдань за вагою обчислень за зростанням FASTEST


Режим пріоритетизації: сортування завдань за вагою обчислень за зростанням. Режим призначення ресурсів: FASTEST.

На рисунку 4.13 зображена порівняльна гістограма часу виконання задач в GRID в залежності від кількості задач для планування.

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


Рисунок 4.13 Час виконання задач


Приріст продуктивності можна побачити в таблиці 4.5.


Таблиця 4.5 Приріст продуктивності GRID системи

Кількість задач1002003004005006007008009001000Приріст продуктивності, %20,519,016,220,417,612,314,925,019,013,6

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

На рисунку 4.14 зображена порівняльна гістограма завантаженості вузлів системи.

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


Рисунок 4.14 Завантаженість вузлів GRID


На рисунку 4.15 зображена порівняльна гістограма часу перебування задач в черзі планувальника в залежності від кількості задач для планування.


Рисунок 4.15 Час перебування задач в черзі планувальника


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

4.6 Сортування завдань за вагою обчислень за спаданням FASTEST


Режим пріоритетизації: сортування завдань за вагою обчислень за спаданням. Режим призначення ресурсів: FASTEST.

На рисунку 4.16 зображена порівняльна гістограма часу виконання задач в GRID в залежності від кількості задач для планування.


Рисунок 4.16 Час виконання задач


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

Приріст продуктивності можна побачити в таблиці 4.6.


Таблиця 4.6 Приріст продуктивності GRID системи

Кількість задач1002003004005006007008009001000Приріст продуктивності, %14,916,117,321,925,023,423,420,417,619,0

Середній приріст продуктивності - 19,9%.

На рисунку 4.17 зображена порівняльна гістограма завантаженості вузлів системи.

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


Рисунок 4.17 Завантаженість вузлів GRID


На рисунку 4.18 зображена порівняльна гістограма часу перебування задач в черзі планувальника в залежності від кількості задач для планування.


Рисунок 4.18 Час перебування задач в черзі планувальника


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

З наведених даних видно, що використання модифікованого алгоритму завжди дає приріст продуктивності GRID-системи порівняно з використанням базового. Приріст становить від 6,6% до 22%. Причому для режиму призначення FIRSTAVAILABLE приріст менший, ніж для режиму FASTEST. Це пояснюється тим, що третя модифікація алгоритму (призначення вузлів, швидкість зєднання з якими нижча, задачам з меншою кількістю даних) не призначена для режиму FIRSTAVAILABLE.

Завантаженість вузлів при використанні базового алгоритму завжди нерівномірна. Для режиму FIRSTAVAILABLE завантаженість вузла залежить від порядкового номеру його присутності в списку планувальника - перші вузли найбільш завантажені. Для режиму FASTEST більш завантаженими є найпродуктивніші вузли.

При використанні модифікованого алгоритму завантаженість вузлів рівномірна для всіх режимів роботи.

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


5. Апаратна частина. розробка кодового замка


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


5.1 Вибір та обгрунтування технічних рішень


.1.1 Постановка задачі

Розробити електронний кодовий замок, що має 10 кнопок для введення коду, позначених цифрами від «0» до «9». Замок повинен мати перемикач режимів «Запис / Робота», кнопку «Сброс» в разі набору невірної цифри. Передбачається зміна встановленого коду. Довжина коду - 6 десяткових цифр. Після правильно введеного коду повинна загоратися лампочка.

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

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

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

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


.1.2 Огляд варіантів реалізації структурної схеми пристрою

Основна структурна схема буде схожа у всіх перерахованих варіантах, змінюватися будуть лише складові її елементи:






Рисунок 5.1 Структурна схема №1









Рисунок 5.2 Структурна схема №2













Рисунок 5.3 Структурна схема №3


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

Структурна схема №2 зображена на рисунку 5.2 схожа на схему №1 (рисунок 5.1). Вона відрізняється лише тим, що функція введення / виведення відбуватиметься за допомогою одного пристрою (сенсорного дисплея).

Третя схема відображає у собі ускладнену другу схему.

За основну структурну схему мною було обрано перший варіант з наступних причин:

-Простота перенесення даної структурної схеми на схематичне проектування і програмний аспект пристрою;

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

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


.1.3 Обгрунтування вибору мікроконтролера

Основними вимогами, що пред'являються до мікроконтролера в даному проекті, є:

-Наявність паралельних портів введення / виведення в кількості, достатній для підключення всіх пристроїв, що входять в структурну схему системи;

-Досить висока надійність і стабільність роботи;

Можливість роботи в розширеному температурному діапазоні.

Враховуючи всі ці вимоги, як пристрій управління було обрано мікроконтролер PIC16F676 (8-розрядний КМОН мікроконтролер з Flash пам'яттю, заснований на AVR-архітектурі RISC, дозволяє досягти оптимального співвідношення продуктивності до споживаної енергії).


Рисунок 5.4 Мікроконтролер PIC16F676


Основні причини вибору:

-Велика кількість довідкової інформації, прикладів роботи з мікроконтролером, книг з програмування даного МК;

-PIC16F676 недорогий в порівнянні з іншими мікроконтролерами, має низьке енергоспоживання;

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

-Даний мікроконтролер доступний на радіо ринках у достатній кількості;

Існує велика кількість компіляторів на безлічі прикладних мов, у тому числі і компілятор від розробника даного мікроконтролера, що дає додаткову підтримку від виробника;

-МК має усі необхідні функції і пристрої для роботи в проектованій системі.

Загальні характеристики МК:

-Високопродуктивний RISC-процесор;

-Всього 35 простих інструкцій;

Усі інструкції виконуються за один такт (200 нс), окрім інструкцій переходу, виконуваних за 2 такти (мінімальна довжина такту - 200 нс);

14 бітові команди;

8 бітові дані;

Вхід зовнішніх переривань;

8 рівневий апаратний стек;

Прямий, непрямий та відносний режими адресації для даних та інструкцій.

Периферія:

-22 лінії вводу / виводу з індивідуальним контролем напрямку;

-Потужнострумові схеми портів вводу / виводу:

25 ма макс. Витік. Струм;

25 ма макс. Втік. Струм;

Timer0: 8-розрядний таймер / лічильник;

Timer1: 16-розрядний таймер / лічильник;

Timer2: 8-розрядний таймер / лічильник;

2 ШІМ модуля;

Послідовні інтерфейси;

3-дротовий SPI;

I2C Master та Slave режими;

USART (з підтримкою адреси);

5 каналів 10 бітного АЦП;

2 аналогових компаратори;

Інтегрований програмований джерело опорної напруги.

Особливості мікроконтролера:

-Скидання при включенні живлення (POR);

-Таймер включення живлення ( PWRT ) і таймер запуску генератора (OST);

Скидання по зниженню напруги живлення (BOR);

Таймер (WDT) з власним вбудованим RC-генератором для підвищення надійності роботи;

Режим економії енергії (SLEEP);

Вибір джерела тактового сигналу;

Програмування на платі через послідовний порт (ICSPT) (з використанням двох виводів);

Налагодження на платі через послідовний порт (ICD) (з використанням двох виводів);

Можливість самопрограмування;

Програмовуваний захист коду;

1000 циклів запису / стирання FLASH пам'яті програми;

100 000 циклів запису / стирання пам'яті даних ЕСППЗУ;

-Період зберігання даних ЕСППЗУ > 40 років.

Технологія КМОН:

Економічна високошвидкісна технологія КМОН;

-Повністю статична архітектура;

Широкий робочий діапазон живлення - від 2,0В до 5,5В;

Промисловий і розширений температурний діапазони;

Низьке споживання енергії.


5.2 Розробка структурної схеми пристрою







Рисунок 5.5 Функціональні блоки пристрою


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


Рисунок 5.6 Алгоритм роботи структурної схеми


5.3 Розробка принципової та функціональної схем пристрою


Рисунок 5.7 Принципова схема пристрою


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

На ній видно як між собою пов'язані складові елементи системи: мікроконтролер, клавіші і світлодіоди.

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

Рисунок 5.8 Функціональна схема пристрою


Вище представлена функціональна схема проектованого пристрою. Пристрій управляється мікроконтролером PIC16F676.

Контролер сканує підключену до його портів клавіатуру за певним принципом і у випадку натискання клавіші аналізує її код (який складається з номера рядка і стовпчика) запускаючи за його значенням певні процедури.


6. Охорона праці та безпека у надзвичайних ситуаціях


6.1 Вступ


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

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


6.2 Опис приміщення


Рисунок 6.1 План приміщення


Розміри приміщення: довжина: 5 м, ширина: 4 м, висота: 3 м, площа: 20 м², обєм: 60 м³. Вікна виходять на північ, стіни пофарбовані у світлозелений колір. У кімнаті знаходиться 2 робочих місця.

Згідно з вимогами [37] <#"justify">6.3 Напруженість праці користувача ПЕОМ


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

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

Виходячи з характеру розробленого у ДП програмного продукту та згідно з [39] робота користувача ПЕОМ (системного програміста) за показниками напруженості трудового процесу відноситься:

-За показником інтелектуального навантаження - I клас (сприймання інформації не потребує коррекції та перевірки даних)

-За сенсорним навантаженням - II клас (можлива необхідність тривалого спостереження за більш ніж 5 виробничими обєктами)

За емоційним навантаженням - I клас (не має ризику та не вимагає додаткових зусиль в роботі з боку працівника)

За монотонністю навантажень - II клас (кількість прийомів необхідних для реалізації завдання - 6-9, тривалість їх виконання приблизно 60 с.)

За режимом праці - I клас (однозмінна робота, без нічної зміни, 6-годинний робочий день)

Встановлено, що характер робіт, виконуваних користувачем при роботі з розробленим в дипломному проекті програмним продуктом підпадає під I клас - оптимальні умови та характер праці. Загальна оцінка напруженості трудового процесу - 2.


6.4 Повітряне середовище


Згідно з [40] виконувані за ЕОМ роботи підпадають під категорію робіт легкі І-а - фізичні роботи, що виконуються сидячи і не потребують фізичного напруження.

Нижче приведено відповідні санітарні вимоги до мікроклімату в приміщенні, які повинні дотримуватися.


Таблиця 6.1 Оптимальні величини температури, відносної вологості та швидкості руху повітря в робочій зоні виробничих приміщень

Період рокуТемпература повітря, град.СВідносна вологість повітря, %Швидкість руху повітря, м/сек.Холодний22-2460-400.1Теплий23-2560-400.1

Таблиця 6.2 Допустимі величини температури, відносної вологості та швидкості руху повітря в робочій зоні виробничих приміщень

Період рокуТемпература, °СВідносна вологість (%) на робочих місцяхШвидкість руху (м/сек.) На робочих місцяхВерхня межаНижня межаХолодний252175Не більше 0.1Теплий282255 - при 28°С0.2 - 0.1

Таблиця 6.3 Рівні іонізації повітря в робочій зоні виробничих приміщень

РівніКількість іонів в 1 см куб. Повітря+n-nМінімальні400600Оптимальні1500-30003000-5000Максимальні5000050000

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

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

Згідно з [46] повинна використовуватися централізована система водяного опалення низького тиску. Ці заходи забезпечать належний мікроклімат у використовуваному приміщенні.


6.5 Виробничий шум


Згідно з [41] допустимий шум на постійних робочих місцях творчої діяльності, проектування, програмування та ін., має бути 50 дба. Середній рівень шуму при роботі з ЕОМ складає близько 45 дба. Таким чином, робота з системою, розробленою в дипломному проекті, являється безпечною і не потребує додаткових улаштувань для зниження шуму, окрім загальних методів ізоляції від зовнішнього шуму. Для цього застосовуються спеціальні віконні профілі та звукоізоляція зовнішніх стін плитами зі звукоізоляційними наповнювачами.


6.6 Електробезпека


Згідно з [47] робоче місце підпадає під категорію без підвищеної небезпеки.

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

Основними причинами електротравматизму є:

-Випадкове доторкання до неізольованих струмопровідних частин електроустаткування;

-Старіння ізоляції і втрата нею ізоляційних властивостей;

Застосування нестандартних або несправних переносних світильників напругою 220 чи 127 В;

Робота без надійних засобів та запобіжних пристосувань;

Доторкання до незаземлених корпусів електроустаткування, що опинилися під напругою внаслідок пошкодження ізоляції;

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


Таблиця 6.4 Граничні допустимі напруги і струми дотику, що протікають через тіло при нормальному режимі електроустановки

Рід струмуU, ВI, маЗмінний, 50 Гц2.00.3

Таблиця 6.5 Граничні допустимі напруги і струми дотику, що протікають через тіло при аварійному режимі електроустановки

Рід струмуВеличинаЗначення при тривалості впливу, сБільше 1.0 сЗмінний, 50 ГцU, В I, ма20 6

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

Згідно з [48] у робочих приміщеннях все електрообладнання відповідає нормам електробезпеки. ЕОМ мають заземлення та якісну ізоляцію, і підключені до електромережі через спеціальні мережні фільтри, також для забезпечення безпеки введено регулярну перевірку кваліфікованими працівниками електрообладнання та ізоляції на предмет можливого порушення.


6.7 Пожежна безпека приміщення


Будівля і та її частина, в який розташовуються ЕОМ, повинна мати не нижче II ступеня вогнестійкості. Згідно з [42] приміщення відноситься до категорії В - пожежонебезпечна. (На робочому місці наявні наступні пожежонебезпеці матеріали: папір, пластик, віконні рами, деревяні шафи, корпуси техніки, меблі.)

Згідно з [43] висота та ширина шляхів евакуації встановлюється нормативними документами відповідно до призначення будинку. При цьому висота шляхів евакуації повинна бути не меншою як 2,0 м, а їхня ширина - 1,0 м. Ширину проходів до одиночних робочих місць у межах одного приміщення дозволяється зменшувати до 0,7 м.

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

При нормальному режимі роботи можливість виникнення пожежі мінімальна. Можливість виникнення вибухів повністю відсутня.

Можливими причинами загоряння можуть бути пошкодження та замикання в електромережі та електрообладнанні, а також порушення правил безпеки при роботі з обладнанням.

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

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

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

Дозволяється гасити лише порошковими або вуглекислотними вогнегасниками, але в жодному випадку не пінними.

Проектом передбачені наступні заходи пожежної безпеки:

-Система пожежної сигналізації;

-Застосовуються вуглекислотні вогнегасники;

Заземлені конструкції, що знаходяться в приміщеннях (батареї опалення, водопровідні труби, кабелі із заземленим відкритим екраном тощо) захищені діелектричними щитками від випадкового дотику;

У приміщеннях з ЕОМ, щоденно проводиться вологе прибирання;

Застосовуються автоматичні системи гасіння пожежі;

Робоче приміщення повинно бути обладнане двома вуглекислотними вогнегасниками ВВК 3,5 з розрахунку два вогнегасника на 20 м² (згідно з [44]).


6.8 Гігієнічні вимоги до організації і обладнання робочого місця


Конструкція робочого місця користувача має забезпечувати підтримання оптимальної робочої пози.

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

Столи розміщені так, що відстань між бічними поверхнями моніторів складає 1,5 м.

Робочий стілець підйомно-поворотний, регульований за висотою. Висота поверхні сидіння регулюється від 400 мм до 500 мм, а ширина і глибина становить 450 мм.

Екран розташовано на відстані від очей користувача, що становить 700 мм під кутом + 30 град. До нормальної лінії погляду працюючого.

Клавіатура розташована на поверхні столу на відстані 200 мм від краю, звернутого до працюючого.

Взаємне розташування елементів робочого місця влаштовує [37].


6.9 Висновки та рекомендації з поліпшення умов праці


З огляду на проведені дослідження можна підсумувати що:

-Розмір, розташування та оснащення робочого місця системного програміста відповідає нормам зазначеним у [37];

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

Згідно з [48] у робочих приміщеннях все електрообладнання відповідає нормам електробезпеки;

При нормальному режимі роботи можливість виникнення пожежі мінімальна. Можливість виникнення вибухів повністю відсутня. В разі виникнення пожежі в приміщенні є 2 вогнегасники та продумана система евакуації;

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

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

. До включення устаткування:

.1 Перевірити правильність розташування обладнання:

-Кабелі електроживлення ПЕОМ та іншого обладнання повинні знаходитися з тильної сторони робочого місця;

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

.2 Перевірити надійність підключення до системного блоку роз'ємів периферійного обладнання.

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

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

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

. У разі виникнення аварійної ситуації - негайно відключити ЕОМ з ВДТ і ПП від електричної мережі.

. Не допускається:

-Виконувати обслуговування, ремонт та налагодження ЕОМ з ВДТ і ПП безпосередньо на робочому місці оператора;

-Зберігати біля ЕОМ з ВДТ і ПП папір, дискети, інші носії інформації, запасні блоки, деталі тощо, якщо вони не використовуються для поточної роботи;

Відключати захисні пристрої, самочинно проводити зміни у конструкції та складі ЕОМ з ВДТ і ПП або їх технічне налагодження;

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

Працювати з ВДТ, у яких під час роботи з'являються нехарактерні сигнали, нестабільне зображення на екрані тощо.


Висновки


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

Після огляду існуючих систем було обрано один з найбільш популярних планувальників - Moab Workload Manager для детального аналізу, в ході якого були виявлені наступні недоліки даної системи:

Нерівномірна загрузка вузлів;

Дана система не враховує час очікування задач на передачу;

Великий час простою вузлів.

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

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

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

Моделювання роботи обох алгоритмів на розробленому програмному забезпеченні підтвердило висновки щодо недоліків алгоритму, покладеного в основу Moab Workload Manager, та щодо більш ефективної роботи модифікованого алгоритму.

Також в даній роботі розглянуті питання забезпечення охорони праці.


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

планування програмний алгоритм

1)I. Foster, C. Kesselman. GRID: A Blueprint to the New Computing Infrastructure. Morgan Kaufman Publishers, 1999.

)Foster, What is Grid? A three point check, 2002

3)Chervenak, A., Foster, I., Kesselman, C., Salisbury, C. And Tuecke, S. The Data GRID: Towards an Architecture for the Distributed Management and Analysis of Large Scientific Data Sets. J. Network and Computer Applications, 2001

)Childers, L., Disz, T., Olson, R., Papka, M.E., Stevens, R. And Udeshi, T. Access GRID: Immersive Group-to-Group Collaborative Visualization. In Proc. 4th International Immersive Projection Technology Workshop, 2000.

)Clarke, I., Sandberg, O., Wiley, B. And Hong, T.W., Freenet: A Distributed Anonymous Information Storage and Retrieval System. In ICSI Workshop on Design Issues in Anonymity and Unobservability, 1999

)Czajkowski, K., Fitzgerald, S., Foster, I. And Kesselman, C. GRID Information Services for Distributed Resource Sharing, 2001.

)Коваленко В.Н., Коваленко Е.И., Корягин Д.А., Любимский Э.З. Метод опережающего планирования для грид, 2005

)Foster I., Kesselman C., J. Nick, Tuecke S. The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration, 2004

)Ian Foster, Jeffrey Frey, Steve Graham, Steve Tuecke, Karl Czajkowski, Don Ferguson, Frank Leymann, Martin Nally, Igor Sedukhin, David Snellin, Tony Storey, William Vambenepe, Sanjiva Weerawana. Modeling Stateful Resources with Web Services, 2005

10) D.P. da Silva, W. Cirne, and F.V. Brasileiro. Trading Cycles for Information: Using Replication to Schedule Bag-of-Tasks Applications on Computational Grids. In Proc. Of europar 2003, volume 2790 of Lecture Notes in Computer Science, 2003.

11) Таненбаум Э. Распределенные системы. Принципы и парадигмы. / Э. Таненбум, М. Ван Стеен. - спб. : Питер, 2003. - 877 с.

12) ISO: «Open Distributed Processing Reference Model.» International Standard ISO/IEC IS 10746, 1995.

13) Neuman, В.: «Scale in Distributed Systems.» In Casavant, T. And Singhal, M. (eds.). Readings in Distributed Computing Systems, pp. 463-489. Los Alamitos, С A: IEEE Computer Society Press, 1994.

14) Grid Computing. Making the Global Infrastructure a Reality. Edited by F. Berman, G.Fox, T.Hey. - Wiley, 2003. - 1012 p.

15) V. Hamscher, U. Schwiegelshohn, A. Streit, R. Yahyapour, Evaluation of Job-Scheduling Strategies for Grid Computing, in Proc. Of GRID 2000 GRID 2000, First IEEE/ACM International Workshop, pp. 191-202, Bangalore, India, December 2000.

16) F. Berman, R. Wolski, H. Casanova, W. Cirne, H. Dail, M. Faerman, S. Figueira, J.Hayes, G. Obertelli, J. Schopf, G. Shao, S. Smallen, N. Spring, A. Su and D.Zagorodnov, Adaptive Computing on the Grid Using apples, in IEEE Trans. On Parallel and Distributed Systems (TPDS), Vol.14, No.4, pp.369-382, 2003.

) F.D. Sacerdoti, M.J. Katz, M.L Massie and D.E. Culler, Wide area cluster monitoring with Ganglia, in Proc. Of IEEE International Conference on Cluster Computing, pp.289 - 298, Hong Kong, December 2003.

) P. Buncic, A. J. Peters, P.Saiz. The alien system, status and perspectives. Computing in High Energy and Nuclear Physics, 24-28 March 2003, La Jolla, California.

19)R. Raman, M. Livny, and M. Solomon. Matchmaking: An extensible framework for distributed resource management. Cluster Computing, 2(2), 1999.

20)The nordugrid architecture and tools. P. Eerola et al. Computing in High Energy and Nuclear Physics, 24-28 March 2003, La Jolla, California.

) Jon B.Weissman, P. Srinivasan. Ensemble Scheduling: Resource Co-Allocation on the computationalgrid, 2001

) Matthias Hovestadt, Odej Kao, Axel Keller, and Achim Streit. Scheduling in HPC Resource Management Systems: Queuing vs. Planning

) A. Keller and A. Reinefeld. Anatomy of a Resource Management System for HPC Clusters. In Annual Review of Scalable Computing, vol. 3, Singapore University Press, pages 1-31, 2001.

)V. Hamscher, U. Schwiegelshohn, A. Streit, and R. Yahyapour. Evaluation of job-scheduling strategies for grid computing. Lecture Notes in Computer Science, pages 191-202, 2000.

) H. Topcuoglu, S. Hariri, M.Y. Wu, Performance-Effective and Low-Complexity Task Scheduling for Heterogeneous Computing, IEEE Transactions on Parallel and Distributed Systems, Vol. 13, No. 3, pp. 260 - 274, 2002.

26)Планувальник Maui: http://www.supercluster.org/maui

27)Dror G., Feitelson, Ahuva Mu'alem Weil «Utilization and Predictability in Scheduling the IBM SP2 with Backflling», The Hebrew University of Jerusalem, 2004

28)Коваленко В.Н., Семячкин Д.А. «Использование алгоритма BACKFILL в ГРИД», Институт прикладной математики им. М.В.Келдыша РАН, Москваб 2005г.

29)R. Buyya, M. Murshed, D. Abramson, «A Deadline and Budget Constrained Cost-Time Optimization Algorithm for Scheduling Task Farming Applications on Global Grids», Proceedings of the 2002 International Conference on Parallel and Distributed Processing Techniques and Applications, Las Vegas, USA, 2002

30)В.Н. Коваленко, А.В. Орлов «Управление заданиями в распределенной среде и протокол резервирования ресурсов», Институт прикладной математики им. М.В.Келдыша РАН, Москва, 2002г.

)«EGEE Users Guide. WMS service», May 3, 2006

)Technilal whitepaper «Open source metascheduling for Virtual Organizations with the Community Scheduler Framework (CSF)», Platform Computing Corporation, Canada, 2003

33)Проект nordugrid: http://www.nordugrid.org/middleware/

34)Walfredo Cirne, Francisco Brasileiro, Lauro Costa, Daniel Paranhos, Elizeu Santos-Neto, Nazareno Andrade, Cesar De Rose, Tiago Ferreto, Miranda Mowbray, Roque Scheer, Joao Jornada «Scheduling in Bag-of-Task Grids: The PAUA Case», 2000

)S. Cavalieri, S. Monforte «Resource Broker Architecture and apis», University of Catania, June 2008

36)Цвитун А.А., Корнейчук В.И., Долголенко А.Н. Надёжность компьютерных сетей, Киев: «Корнейчук», 2010 г

)Державні санітарні правила і норми роботи з візуальними дисплейними терміналами електронно-обчислювальних машин дсанпін 3.3.2.007-98 (затверджено Постановою Головного державного санітарного лікаря України від 10.12.1998 р. № 7).

)Правила охорони працi пiд час експлуатацii електронно-обчислювальних машин. НПАОП 0.00-1.28-10 (затверджено наказом Державного комітету України з промислової безпеки, охорони праці та гірничого нагляду від 26.03.2010р. № 65).

)Гігієнічна класифікація праці за показниками шкідливості та небезпечності факторів виробничого середовища, важкості та напруженості трудового процесу (затверджено наказом МОЗ України від 27.12.2001р № 528)

)Санiтарнi норми мiкроклiмату виробничих примiщень. ДСН 3.3.6.042-99 (затверджено Постановою Головного державного санітарного лікаря України від 1.12.1999 р. № 42).

)Санiтарнi норми виробничого шуму, ультразвуку та iнфразвуку. ДСН 3.3.6.037.99 (затверджено Постанова Головного Державного санітарного лікаря України від 1.12.1999 р. № 37).

)Норми визначення категорій приміщень, будинків та зовнішніх установок за вибухопожежною та пожежною небезпекою. НАПБ Б.03.002-2007. (затверджено наказом МНС України від 03.12.2007 № 833)

)Пожежна безпека на обєктах будівництва ДБН В.1.1.7-2002 (затверджено наказом Держбуду України від 03.12.2002 р. № 88)

)Типові норми належності вогнегасників (затверджено наказом Міністерства України з питань надзвичайних ситуацій та у справах захисту населення від наслідків Чорнобильської катастрофи від 2 квітня 2004 р. N 151).

)Державні нормативні акти та правила охорони праці під час експлуатації електронно-обчислювальних машин ДНАОП 0.00-1.31-99 (затверджено наказом Президента України від 9 березня 1998 р. N 182/98).

)Будівельні норми та правила. Опалення, вентиляція та кондиціювання снип 2.04.05-91 (затверджено Державним комітетом України від 27 червня 1996 р. N 117).

)Державні нормативні акти та Правила безпечної експлуатації електроустановок споживачів ДНАОП 0.00-1.21-98 (затверджено наказом Державного комітету України по нагляду за охороною праці від 16.03.94 р. N 19).

)Правила улаштування електроустановок ПУЕ 2009 - К.: Держенергонагляд України, 2009 р.-288 с.


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

Больше работ по теме:

КОНТАКТНЫЙ EMAIL: [email protected]

Скачать реферат © 2017 | Пользовательское соглашение

Скачать      Реферат

ПРОФЕССИОНАЛЬНАЯ ПОМОЩЬ СТУДЕНТАМ