Transcript GRMS - System Zarządzania Zadaniami Interfejs użytkownika systemu GRMS - wprowadzenie Bogdan Ludwiczak [email protected] GRMS co to jest / do czego to służy? • GRMS jest systemem.

GRMS - System Zarządzania
Zadaniami
Interfejs użytkownika systemu
GRMS - wprowadzenie
Bogdan Ludwiczak
[email protected]
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.pdf