Студопедия
Главная страница | Контакты | Случайная страница

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

Адміністрування PVM

Читайте также:
  1. АДМІНІСТРУВАННЯ
  2. Вимоги до актів публічного адміністрування та наслідки їх порушення
  3. Дія та чинність актів публічного адміністрування
  4. Європейські принципи адміністративного права в сфері публічного адміністрування та надання адміністративних послуг.
  5. Лекція Т.1. Загальне поняття про техніку та технології адміністрування.
  6. ТЕМА 14. АДМІНІСТРУВАННЯ ПОДАТКІВ: ЗАХІДНИЙ ДОСВІД ТЕОРІЇ ТА ПРАКТИКИ
  7. Тема 8. Правові основи адміністрування податків в Україні

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

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

Для запуску віртуальної машини необхідно виконати команду pvm. Ця команда запускає консоль паралельної віртуальної машини PVM. Команда pvm перед запуском консолі перевіряє наявність у системі демона pvmd, запущеного від імені користувача, який виконує команду pvm. Таким чином в системі можуть бути присутні кілька демонів pvmd (кілька паралельних віртуальних машин), що належать різним користувачам. З іншого боку два користувачі, що підключилися до консолі кластера під одним ім'ям, будуть користуватися однією і тією ж віртуальною машиною. Доступ користувачів до консолі під різними іменами забезпечити безпеку для виконуваних програм. Оскільки запущені програми будуть виконуватися під різними віртуальними машинами, то користувачі не зможуть перешкодити один одному, наприклад зняти з виконання чуже завдання. З іншого боку, робота всіх користувачів під одним login'ом забезпечить простоту адміністрування запущених завдань. У цьому випадку користувач може бути позбавлений необхідності самостійно конфігурувати склад кластеру. Проте це додасть ризик неправомірного впливу користувачем на чужі завдання. Користувач може, наприклад, зупинити віртуальну машину командою halt, знявши тим самим з виконання всі запущені в рамках цієї віртуальної машини завдання. Яким чином забезпечити користувачам доступ до консолі кластеру ви повинні вирішити самостійно.

Запустивши команду pvm, користувач потрапляє в командний рядок віртуальної машини. Список допустимих в PVM команд можна отримати, виконавши команду help. Далі ми розглянемо лише ті команди, які будуть постійно необхідні для виконання завдань на паралельному комп'ютері під управлінням PVM.

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

pvm> add node1

pvm> add 192.168.1.3

pvm> add node3.cluster.mydomain.org

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

pvm> add node1

add node1

user1 @ node1's password:

1 successful

HOST DTID

node1 80000

pvm>

Переглянути список підключених до віртуальної машини вузлів можна видавши команду conf:

pvm> conf

conf

2 hosts, 1 data format

HOST DTID ARCH SPEED DSIG

server 40000 LINUX 1000 0x00408841

node1 80000 LINUX 1000 0x00408841

pvm>

Для кожної машини списку дана інформація, що включає в себе ім'я машини (коротке або повне доменне ім'я, або ip-адреса) HOST, ідентифікатор завдання DTID демона PVM, назву архітектури підключення машини ARCH, якесь число SPEED, що відображає швидкісні характеристики машини та ідентифікатор самої віртуальної машини DSIG, яка буде розрізнена для віртуальних машин, запущених різними користувачами.

Замість того, щоб вручну додавати кожен вузол кластеру у віртуальну машину, можна при першому запуску pvm вказати в якості першого параметра команди ім'я текстового файлу, в якому перераховані імена (короткі або повні доменні) або ip-адреси вузлів кластеру. Правило складання такого файлу просте: один вузол - один рядок. У разі використання списку вузлів, PVM самостійно виконає підключення перерахованих у файлі машин. Ймовірно пріавильним і зручним буде забезпечити безпарольний доступ по протоколу SSH до вузлів кластеру з консолі кластера і виконання команди "pvm hostlist" з startup-файлу користувача (наприклад. Bashrc).

Наступний крок, яким систематично буде займатися користувач, перебуваючи у віртуальній машині, це запуск паралельних завдань. Запуск здійснюється командою spawn. Як параметр цієї команди вказується назва виконуваного файлу, який слід запустити всередині віртуальної машини. Файл з такою назвою шукається в каталозі / pvm3/bin/LINUX /.

pvm> spawn timing

spawn timing

1 successful

t40002

pvm>

У наведеному прикладі виконується запуск програми "timing". У цьому варіанті програма запускається у фоновому режимі і весь висновок в STDOUT буде записуватися в log-файл. Команду запуску можна модифікувати з тим, щоб висновок в STDOUT від всіх процесів завдання спрямований на консоль віртуальної машини. Для цього команда запуску і виведення програми на екрані будуть виглядати так:

pvm> spawn -> hello

spawn -> hello

[1]

1 successful

t40004

[1: t40005] Message from slave process

[1: t40004] i'm t40004

[1: t40004] from t40005: hello, world from yis

[1: t40005] EOF

[1: t40004] EOF

[1] finished

pvm>

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

pvm> ps-a

ps-a

HOST TID FLAG 0x COMMAND

server 40002 6 / c, f timing

node1 80002 6 / c, f timing_slave

pvm>

У прикладі ми бачимо, що запущене нами завдання timing залишилася працювати на консолі кластеру "server" і породила на сайті "node1" дочірній процес timing_slave.

Для зняття процесу з рахунку можна скористатися командою kill, параметрами якої є ідентифікатори завдань (TID) процесів, які підлягають видаленню з системи. Ідентифікатори завдань можна подивитися за допомогою раніше описаної команди ps. Так, для видалення з системи процесів "timing" і "timing_slave" з попереднього прикладу, команда ps буде виглядати наступним чином:

pvm> kill 40002 80002

Для видалення всіх завдань слід скористатися командою reset:

pvm> reset

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

pvm> quit

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

У тому випадку, коли необхідно зняти з виконання всі паралельні завдання і зупинити роботу паралельної віртуальної машини, використовується команда halt.

pvm> halt

Результатом виконання цієї команди є, по-перше, "вбивання" всіх процесів віртуальної машини на всіх приєднаних до неї вузлах кластеру (у тому числі і на консолі кластера), по-друге, зупинка системи PVM на всіх вузлах кластера (від'єднання вузлів), й, на закінчення, зупинка системи PVM на консолі кластера з виходом до командний рядок локальної операційної системи.

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

10.5 Інтерфейс передачі повідомлень (MPI)

 

MPI розшифровується як "Message passing interface" ("Інтерфейс передачі повідомлень"). MPI - це стандарт на програмний інструментарій для забезпечення зв'язку між окремими процесами паралельного завдання. MPI надає програмісту єдиний механізм взаємодії процесів всередині паралельно виконуваного завдання незалежно від машинної архітектури (однопроцесорні, багатопроцесорні із загальною або роздільного пам'яттю), взаємного розташування процесів (на одному фізичному процесорі або на різних) і API операційної системи. Програма, що використовує MPI, легко регламентоватима і переноситься на інші платформи, часто для цього досить простої перекомпіляції вихідного тексту програми.

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

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

В даний час різними колективами розробників написано кілька програмних пакетів, що задовольняють специфікації MPI, зокрема: MPICH, LAM, HPVM, OpenMPI і так далі. У двох словах охарактеризуємо найбільш поширені з цих пакетів. Якщо говорити про LAM, то основна перевага цього пакету - багаті налагодження можливостей. Трасування звернень до MPI та аналіз стану паралельної програми після аварійного завершення роблять процес налагодження менш важким і більш продуктивним. З іншого боку, пакет MPICH більш мобільний, слідуючи простим інструкціям можна перенести MPI на нову платформу (наприклад з Linux на Windows або навпаки). Для цього потрібно написати лише кілька драйверів нижнього рівня. Установка бібліотеки MPICH проходить трохи важче, ніж установка LAM MPI, оскільки доводиться задавати набагато більше число параметрів, причому призначення деяких з них відомо тільки розробникам.

MPI - це добре стандартизований механізм для побудови програм по моделі обміну повідомленнями. Існують стандартні "прив'язки" MPI до мов С/С + +, Fortran 77/90. Є і безкоштовні і комерційні реалізації майже для всіх суперкомп'ютерних платформ, а також для High Performance кластерних систем, побудованих на вузлах з ОС Unix, Linux та Windows. В даний час MPI - найбільш широко використовується і динамічно розвивається інтерфейс зі свого класу. У новій версії стандарту 2.0 описано велику кількість нових цікавих механізмів і процедур для організації функціонування паралельних програм: динамічне управління процесами, односторонні комунікації (Put/Get), паралельні I/O. Але на жаль, поки немає повних готових реалізацій цієї версії стандарту, хоча частина з нововведень уже активно використовується.

 




Дата добавления: 2015-01-05; просмотров: 120 | Поможем написать вашу работу | Нарушение авторских прав




lektsii.net - Лекции.Нет - 2014-2025 год. (0.008 сек.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав