GRMS - System Zarządzania Zadaniami

Interfejs użytkownika systemu GRMS - wprowadzenie

Bogdan Ludwiczakbogdanl@man.poznan.pl

GRMS co to jest / do czego to służy?• GRMS jest systemem szeregowania zadań

dla dużych, rozproszonych systemów obliczeniowych,

• Główny cel: zarządzać całym procesem obsługi zadań obliczeniowych użytkowników • w sposób satysfakcjonujący użytkowników

(właścicieli zadań) przy spełnieniu wymagań zasobowych aplikacji,

• Jednocześnie administratorzy zasobów (właściciele zasobów) zachowują pełną kontrolę nad zasobami wykonującymi obliczenia.

GRMS co to jest / do czego to służy?• Przygotowany z myślą o wyzwaniach środowisk typu

Grid:– Równoważenie obciążenia między klastrami, – Zdalne zlecanie i kontrola zadań,– Przygotowywanie środowiska wykonawczego zadania przed

jego uruchomieniem, – Kopiowanie plików użytkownika (files staging), – Współpraca z innymi serwisami (CDMS, system

monitorujący itp.)– ...

• Stworzony w oparciu o mechanizmy dynamicznego odkrywania i wyboru zasobów, zaawansowane algorytmy mapowania i szeregowania zadań w środowiskach typu Grid

System GRMS – Funkcjonalność

• uruchamianie zadań użytkownika• listowanie zadań użytkownika z

uwzględnieniem zadanych kryteriów• zarządzanie zadaniami• pobieranie informacji o zadaniach• znajdowanie zasobów spełniających

wymagania użytkownika• notyfikacja• funkcje pomocnicze

Uruchamianie zadań użytkownika (job

submission)• najistotniejsza część funkcjonalności

• zdolność zapuszczenia zadania na zdalnej maszynie– najlepiej spełniającej wymagania

użytkownika– lub na maszynie wskazanej z góry

przez użytkownika

Uruchamianie zadań użytkownika - funkcje

• submitJob – podstawowa funkcja całego systemu

• migrateJob – przeniesienie uruchomionego zadania na zasób na którym zadanie będzie wykonywane z lepszą wydajnością

• suspendJob – zawieszenie wykonywania zadani

• resumeJob – wznowienie zawieszonego zadania

• cancelJob – zatrzymanie zadania

listowanie zadań użytkownika

• getJobsList – zwraca listę (identyfikatorów) zadań należących do użytkownika, opcjonalnie listę można ograniczyć tylko do zadań o zadanym statusie

Cykl życia zadania

Stany zadania w systemie GRMS

• QUEUED – zadanie zostało odebrane i oczekuje na obsługę,

• PREPROCESSING – GRMS wykonuje pewne kroki niezbędne przed uruchomienie zadania – wyszukiwanie zasobów, przenoszenie plików, itp..

• PENDING – zadanie oczekuje w systemie kolejkowym w stanie pending

• RUNNING – zadanie jest wykonywane,• STOPPED – zadanie zakończyło się lub zostało

zcheckpointowane, ale GRMS nie pobrał jeszcze jego plików wyjściowych

Stany zadania w systemie GRMS c.d.

• POSTPROCESSING – GRMS wykonuje pewne kroki po zakończeniu wykonywania zadania, np.: pobieranie plików wyjściowych, czyszczenie katalogu roboczego, itp..

• FINISHED – zadanie zostało zakończone,• SUSPENDED – zadanie zostało zawieszone,• FAILED – wykonanie zadania nie powiodło się• CANCELED – zadanie zostało usunięte przez

użytkownika

GRMS_JOB_ID• Każde zadanie w systemie GRMS w

momencie zlecenia otrzymuje unikalny identyfikator: GRMS_JOB_ID

• Wszelkie operacje na zadaniu wymagają podania jego GRMS_JOB_ID

• Uruchomione zadanie może pobrać swoje własne GRMS_JOB_ID z odpowiedniej zmiennej środowiskowej ustawionej przez GRMS’a

Zarządzanie zadaniami• Rejestrowanie zadania w GRMS dla

checkpointingu• dynamiczne zarządzanie plikami

wyjściowymi i checkpointowymi

Zarządzanie zadaniami - funkcje

• registerApplicationAccess – rejestrowanie danych potrzebnych do checkpointowania zadania. (GRMS_JOB_ID, Web Service)

• addOutputFileDirs, addCheckpointFileDirs – dynamiczne rejestrowanie plików i katalogów wyjściowych i checkpointowych

• getOutputFileDirs, getCheckpointFileDirs – pobieranie listy plików wyjściowych i checkpointowych danego zadania,

• deleteOutputFileDirs, deleteCheckpointFileDirs – wyrejestrowywanie plików

Pobieranie informacji o zadaniach

• Pobieranie złożonych informacji o zadaniu • getJobInfo – czas zlecenia, status, czas

zakończenia, opis stanu, długość historii i ostatni wspis w historii),

• getJobHistory – tablica informacji związanych z historią przetwarzania zadanie (opis zadania, czas uruchomienia, czas zlecenia i zakończenia itp.).

Znajdowanie zasobów• GRMS zwraca listę zasobów

spełniających wymagania użytkownika

• wymagania specyfikowane są przy użyciu tego samego języka co przy uruchamianiu zadań

• findResources – zwraca listę zasobów w formie JMC

Notyfikacja• Jeśli klient (n.p. portal) lub serwis

chcą byś informowane przez GRMS’a n.p. o zmianach stanu zadania to muszą zaimplementować interfejs notyfikacji i zarejestrować się w GRMS’ie

• registerNotification • unregisterNotification

Funkcje pomocnicze• testJobDescription –

weryfikowanie poprawności opisu zadania i/lub wymagań zasobowych

GRMS Job Description (GJD)

• Zadania I ich wymagania zasobowe definiowane są przy pomocy języka GJD.

• Opis ten jest dokumentem XML zgodnym ze schemą GJD.

• Elementy dostępne w GJD– job executable:

• lokalizacja pliku binarnego, • argumenty wywołania,• pliki które muszą być dotępne w katalogu roboczym

aplikacji,• zmienne środowiskowe,

GRMS Job Description (GJD)(c.d.)

• standard input,• standard output,• standard error,• checkpoint definition,

– Wymagania zasobowe:• nazwa hosta na którym zadanie ma być wykonane

(jeśli jest określona to GRMS nie wykorzystuje wew. algorytmów rozdziału zasobów),

• system operacyjny,• lokalny system kolejkowy(lsf, pbs, condor, itp.),• minimalna pamięć,

GRMS Job Description (GJD)(c.d.)

• minimalna liczba procesorów,• minimalna prędkość procesorów,• parametry sieciowe (bandwidth, latency

and capacity),• i inne

• Pliki mogą być specyfikowane jako URL’e gridFTP i GASS oraz indentyfikatory systemu zarządzania danymi (np. CDMS)

Krótki przegląd specyfikacji GDJ

• <grmsjob> - główny element GJD, zawiera atrybut "appid" który jest identyfikatorem przypisywanym zadaniu przez użytkownika. Element ten musi zawierać jeden element <simplejob>

Specyfikacja GDJ c.d.• <simplejob> - opisuje “simple job”, które

jest plikiem wykonywalnym i zbiorem parametrów (executable parameters, standard input, output and error streams, environment variables etc.). Opcjonalnie <simplejob> opisuje wymagania zasobowe zadania. <simplejob> musi zawierać element <executable> oraz opcjonalnie jeden <resource>.

Specyfikacja GDJ c.d.• <resource> opisuje wymagania zasobowe

zadania.– Opis wymagań może opcjonalnie zawierać elementy

takie jak:• <ostype> typ systemy operacyjnego,• <osname> nazwa systemu operacyjneg,• <hostname> nazwa host na którym ma zostać wykonane

zadanie,• <localrmname> system kolejkowy ("fork" (domyślnie), "lsf",

"pbs", "sge", “condor”)• <memory> minimalny rozmiar pamięci w MB,• <cpucount> minimalna liczba procesorów,• <cpuspeed> minimalna prędkość procesorów• <bandwidth>, <latency>, <capacity> parametry sieciowe

Specyfikacja GDJ c.d.• Jeśli aplikacja nie została wcześnie

„zainstalowana” na wszystkich dostępnych maszynach obliczeniowych to wymagania zasobowe powinny zawierać informacje o systemie operacyjnym dla którego ją skompilowano lub nazwę maszyny na której powinna zostać wykonana.

Specyfikacja GDJ c.d.• <executable> opis pliku wykonywalnego aplikacji.

Zawiera atrybuty “type” and “count” attributes oraz musi posiadać jeden element <file>. Opcjonalnie zawiera elementy <arguments>, <environment>, <checkpoint>, <stdin>, <stdout>, i <stderr>. – Atrybut “count” oznacza liczbę wykonań aplikacji.– Atrybut “type” oznacza sposób w jaki jobmanager ma

uruchomić aplikację: • single,• multiple,• mpi.

Przykłady opisu zadań• Najprostszy opis programu, który nie potrzebuje żadnych

argumentów, nie ma wymagań zasobowych, a użytkownik nie jest zainteresowany otrzymaniem wyników programu:

<grmsjob appid="appid"><simplejob>

<executable type="single" count="1"><file name="exec-file" type="in">

<url>file:////bin/date</url></file>

</executable></simplejob>

</grmsjob>

• Zadanie identyczne z poprzednim z tym, że program ma być wykonany na określonej przez użytkownika maszynie:

<grmsjob appid="appid"><simplejob>

<resource><hostname>

access.pcss.clusterix.pl</hostname></resource><executable type="single" count="1">

<file name="exec-file" type="in"><url>file:////bin/date</url>

</file></executable>

</simplejob></grmsjob>

• Ponownie /bin/date z tym że wykonane na maszynie z systemem Linux I co najmniej dwoma procesorami:

<grmsjob appid="appid"><simplejob>

<resource><osname>Linux</osname><cpucount>2</cpucount>

</resource><executable type="single" count="1">

<file name="exec-file" type="in"><url>file:////bin/date</url>

</file></executable>

</simplejob></grmsjob>

• Aby wykonanie zadania zostało poprzedzone pobraniem pliku wykonywalnego z określonej lokalizacji należy użyć znacznika <url>

<grmsjob appid="appid"><simplejob>

<executable type="single" count="1"> <file name="exec-file" type="in"> <url>gsiftp://

access.pcss.clusterix.pl/~/date</url> </file></executable>

</simplejob></grmsjob>

• Argumenty wywołania programu przekazywane są w elementach <value> zawartych w sekcji <arguments> section. GJD dla “/bin/echo Hello World”:

<grmsjob appid="appid"><simplejob>

<executable type="single" count="1"><file name="exec-file" type="in">

<url>file:////bin/echo</url></file><arguments>

<value>Hello </value><value>World!</value>

</arguments></executable>

</simplejob></grmsjob>

• Jeśli program potrzebuje określonych plików w swoim katalogu roboczym to należy to opisać przy pomocy elementów <file> tylu “in”:

<grmsjob appid="appid"><simplejob>

<executable type="single" count="1"><file name="exec-file" type="in">

<url>file:////bin/cat</url></file><arguments>

<value>file.log</value><file name="file.log" type="in">

<url>gsiftp://access.pcss.clusterix.pl/~/examples/file.log</url>

</file></arguments>

</executable></simplejob>

</grmsjob>

• Jeśli użytkownik chce pobrać pliki wygenerowane przez program to musi to opisać w sekcji <arguments> przy pomocy elementów <file> typu “out”.

<grmsjob appid="appid"><simplejob><executable type="single" count="1"><file name="exec-file" type="in"> <url>file:////bin/tar</url></file><arguments> <value>cfv</value> <value>file.tar</value> <value>report</value> <file name="report" type="in"> <url>gsiftp:// access.pcss.clusterix.pl/~/examples/report</url> </file> <file name="report.tar" type="out"> <url>gsiftp:// access.pcss.clusterix.pl/~/examples/report.tar</url> </file></arguments></executable></simplejob>

</grmsjob>

• Jeśli program pobiera pewne dane ze stdin to należy to opisać przy pomocy znacznika <stdin> tag.

<grmsjob appid="appid"> <simplejob> <executable type="single" count="1">

<file name="exec-file" type="in"> <url>file:////bin/cat</url> </file> <stdin>

<url>gsiftp://access.pcss.clusterix.pl/~/examples/stdin_file</url> </stdin>

</executable> </simplejob>

</grmsjob>

Dostęp do GRMSa (klienty):• interfejst web-service’owy

– (zaawansowane aplikacje)

• klient linii komend• klient dla urządzeń mobilnych• Portal

Klient linii komend

Klient linii komend w Javie (c.d.)

• grid-proxy-init • grms-client <operation> <parameters>

– grms-client submit <jobDescriptionFile>– grms-client migrate <jobId> [<jobDescriptionFile>]– grms-client suspend <jobId> [<jobDescriptionFile>]– grms-client resume <jobId> [<jobDescriptionFile>]– grms-client cancel <jobId>– grms-client list [QUEUED | PREPROCESSING | PENDING | RUNNING |

STOPPED | POSTPROCESSING | FINISHED | SUSPENDED | FAILED | CANCELED]

– grms-client list_all QUEUED | PREPROCESSING | PENDING | RUNNING | STOPPED | POSTPROCESSING | FINISHED | SUSPENDED | FAILED | CANCELED

– grms-client register <jobId> <service_location> <pid>– grms-client info <jobId>– grms-client history <jobId>– grms-client resources <resourceDescriptionFile>– grms-client test <resourceDescriptionFile>– grms-client add_listener <jobid> <client> [STATUS | REQUEST]

[PROFILE | SMS | MAIL] <listener> [user]– grms-client del_listener <jobid> <notificationId>– grms-client add_output <jobId> <name> <path> [PHYSICAL |

LOGICAL] [FILE | DIRECTORY]– grms-client get_output <jobId>– grms-client del_output <jobId> <name> <path> [PHYSICAL |

LOGICAL] [FILE | DIRECTORY]– grms-client add_output <jobId> <name> <path> [PHYSICAL |

LOGICAL] [FILE | DIRECTORY]– grms-client get_output <jobId>– grms-client del_output <jobId> <name> <path> [PHYSICAL |

LOGICAL] [FILE | DIRECTORY]– grms-client description [SHORT | FULL]

Portal

Klient mobilny

Zadania MPICH-G2• Typ zadania = mpichg

<executable type=mpichg >• Liczba procesów -> atrybut count

<executable ... Count=8>• Wymagania zasobowe:

– W chwili obecnej specyfikować wprost nazwy maszyn

– suma tailSize’ów = count

Dodatkowe informacje i materiały

• http://www.clusterix.pl• http://rage1.man.poznan.pl/clx/grms.ppt• http://rage1.man.poznan.pl/clx/grms-client.p

df