- •Лекція 7. Grid-портал для доступу користувачів до ресурсів і прикладних програм Grid
- •10.1 Будова кластера
- •10.2 Організація мережі обчислювального кластеру
- •10.2.1 Мережеві карти
- •10.2.2 Комутатори
- •10.2.3 Мережеве забезпечення кластеру.
- •10.2.4 Мережева файлова система
- •10.2.5 Конфігурація сервера
- •10.2.6 Конфігурація клієнтів
- •10.2.7 Ssh, беспарольный доступ
- •10.3 Розпаралелювання програм
- •10.3.1 Варіанти декомпозиції
- •10.3.2 Тривіальна декомпозиція
- •10.3.3 Функціональна декомпозиція
- •10.3.4 Декомпозиція даних
- •10.3.5 Regular Domain Decomposition
- •10.3.6 Сітка процесів
- •10.3.7 Зміна елементів даних
- •10.3.8 Область перекриття
- •10.3.9 Граничний обмін
- •10.3.10 Деталізація
- •10.4 Паралельна віртуальна машина (pvm)
- •10.4.1 Взаємодія завдань у pvm
- •10.4.2 Управління завданнями
- •10.4.3 Передача повідомлень
- •10.4.4 Архівування даних
- •10.4.5 Установка pvm
- •10.4.6 Адміністрування pvm
- •10.5 Інтерфейс передачі повідомлень (mpi)
- •10.5.1 Встановлення системи mpi
- •10.5.2 Конфігурація кластеру mpich
- •10.5.3 Конфігурація кластеру lam/mpi
- •10.5.4 Конфігурація кластеру OpenMp
- •10.5.5 Компіляція і виконання
- •10.5.6 Загальна організація mpi
- •Лекція 8. Grid-застосування
10.4.1 Взаємодія завдань у pvm
У системі PVM кожне завдання, запущене на деякому процесорі, ідентифікується цілим числом, яке називається ідентифікатором завдання (TID) і за змістом схоже на ідентифікатор процесу в операційній системі Unix. Система PVM автоматично підтримує унікальність таких ідентифікаторів: копії одного виконуваного файлу, запущеного паралельно на N процесорах PVM, створюють N завдань з різними TID.
За стандартом прийнятому в PVM для взаємодії завдань вважається, що в межах однієї PVM будь-яке завдання може передавати повідомлення будь-якій інший задачі, причому, розміри і кількість таких повідомлень в принципі не обмежені. Це припущення істотно спрощує реалізацію PVM на конкретних обчислювальних комплексах, тому що при цьому контроль переповнення буферних пристроїв і масивів залишається у веденні операційних систем і з програміста знімається одна зайва турбота.
Для підвищення ефективності міжзадачного обміну інформацією передбачено використання декількох алгоритмів. Зокрема, можна використовувати алгоритм блокованої передачі, при якому функція "Надіслати повідомлення" повертає значення (тобто завершує роботу) тільки після того, як отримана позитивна чи негативна квитанція від одержувача повідомлення. Такий алгоритм передачі з очікуванням повідомлення про доставку кращий у тих випадках, коли довге повідомлення передається кількома порціями, а також при обміні командами, послідовність виконання яких у часі повинна бути строго фіксованою.
При використанні неблокованих алгоритмів передачі і прийому повідомлень зменшуються простої процесорів, викликані очікуванням реакції "співрозмовника". Особливо великий ефект це дає на приймальній стороні при невідомому часі приходу повідомлення. Можна організувати роботу приймального процесора так, щоб він в очікуванні повідомлення виконував поточну роботу, лише час від часу опитуючи приймальний буфер.
Суттєвим є та обставина, що при передачі послідовності повідомлення від однієї задачі до іншої порядок прийому повідомлення завжди збігається з порядком їх передачі. Більш того, якщо до звернення до функції "приймає повідомлення" в приймальний буфер приймаючого завдання записано кілька повідомлень, то функція "приймає повідомлення" поверне посилання на перше прийняте повідомлення.
Пам'ять для буферних масивів на передавальній і прийомній стороні виділяється динамічно, отже, максимальний обсяг повідомлень обмежується тільки об'ємом доступної пам'яті. Якщо одне із завдань, запущених в PVM, не може отримати необхідну пам'ять для спілкування з іншими завданнями, то вона видає користувачеві відповідне повідомлення про помилку ("cannot get memory"), але інші задачі про цю подію не сповіщаються і можуть, наприклад, продовжувати посилати їй повідомлення.
10.4.2 Управління завданнями
Управління завданнями в PVM здійснюється на основі деякого набору функцій. Існує два варіанти написання паралельних завдань для PVM. У першому варіанті весь виконуваний на всіх процесорах код пишеться як одне велике завдання. Відповідно на кожному процесорі запускається на виконання один і той же файл. Зазвичай на самому початку своєї роботи програма викликає функцію call pvmfmytid (tid), повертає значення ідентифікатора завдання tid> = 0, яким може визначатися вибір для виконання тієї чи іншої частини програми. Ця функція може викликатися більше одного разу.
Після того, як завдання визначило, що воно головне, виконується запуск решти частин завдання на інших процесорах кластеру. Запуск виконується за допомогою функції:
call pvmfspawn (task, flag, where, ntask, tids, numt);
task - ім'я виконуваного файлу;
INTEGER flag - опції запуску;
where - вказує місце запуску;
INTEGER ntask - число запусщених копій програми;
INTEGER tids - масив значень tid для запущених завдань.
Ця функція запускає в PVM ntask копії виконуваного файлу з ім'ям "task" з однаковими аргументами командного рядка в масиві argv і повертає число запущених завдань numt а також послідовність ідентифікаторів для запущених завдань. Другий варіант написання паралельного завдання полягає в тому, що для кожного процесора пишуться свої власні завдання, що виконують різні дії, і створюється маленька програма, яка, використовуючи функцію pvm_spawn запускає всі інші завдання.
Виконуваний файл для функції pvm_spawn () повинен перебувати в строго визначеному каталозі. Під Unix завдання шукається в каталогах $PVM_ROOT/bin/$PVM_ARCH/ і $HOME/pvm3/bin/ $PVM_ARCH. Задавати ім'я каталогу в параметрі "task" неприпустимо.
Але це не єдиний спосіб. В іншому варіанті виконуваний файл шукається (і запускається) не тільки на тому комп'ютері, на якому працює викликане pvm_spawn () завдання, але в залежності від параметрів flag і where, на будь-якому вхідному до складу PVM. Наприклад, якщо flag == 0, то PVM сам вибирає, на якій з машин запускати нові завдання (головне, щоб додаток був скомпільовано на цих машинах); а якщо flag & PvmMppFront> 0, то місцем запуску буде обраний найшвидший комп'ютер.
Значенням параметра flag задається набір опцій для запускаючих завдань. Кожній опції відповідає ціле невід'ємне число, і значення flag дорівнює сумі обраних опцій. Нижче перераховуються опції запуску задач.
FORTRANe flag може бути сумою таких величин:
PVMDEFAULT = 0 - PVM може вибрати будь-яку машину для старту завдання,
PVMHOST = 1 - параметр where визначає машину для запуску,
PVMARCH = 2 - параметр where визначає тип архітектури,
PVMDEBUG = 4 - процес стартує під відгадчиком,
PVMTRACE = 8 - процес генерує PVM trace data.
Параметр where описує на яких комп'ютерах кластера може бути запущене завдання. Параметр є простою строковою змінною, в яку записано ім'я списку комп'ютерів. Списки комп'ютерів знаходяться у конфігураційних файлах системи PVM і формуються на етапі її установки. Наприклад у випадку, коли у вашому кластері крім консольної машини присутній ще два комп'ютери: один класу P166 та іншой класу P4, ви можете визначити їх в системі під іменами "oldcomp" і "supercomp". І залежно від тих або інших умов, запускати свої завдання на якусь з машин кластеру.
І, нарешті, ще дві функції, пов'язані з управлінням завданнями:
call pvmfkill (tid, info)
call pvmfexit (info)
Перша з них завершує виконання завдання з ідентифікатором tid, повертаючи при помилці код info <0. Відзначимо, що завдання не може таким чином завершити своє виконання. Друга функція завершує роботу PVM, запущеної користувачем, але при цьому сама задача продовжує виконуватися вже як звичайне локальне завдання і завершує роботу звичайним чином.