Infrastruktura QosCosGrid jest zestawem zintegrowanych, wysoce wydajnych usług i narzędzi dostępowych do zarządzania zasobami i zadaniami w wieloklastrowych i gridowych środowiskach obliczeniowych. QosCosGrid wspiera różne scenariusze dla aplikacji, w tym aplikacji równoległych dużej skali, aplikacji parametrycznych oraz złożonych aplikacji typu workflow. Usługi QosCosGrid umożliwiają logiczne scalenie zasobów obliczeniowych pochodzących z wielu klastrów w jeden rozproszony system obliczeniowy. Pozwala to na skrócenie czasu oczekiwania na przydział zasobów oraz na uruchamianie różnego typu zadań obliczeniowych o wymaganiach przekraczających możliwości pojedynczego klastra. Poprzez wykorzystanie zaawansowanych mechanizmów rezerwacji zasobów z wyprzedzeniem, usługi QosCosGrid gwarantują użytkownikowi wymaganą jakość usług obliczeniowych (ang. Quality of Service), w tym czas wykonania zadania. Usługi QosCosGrid zostały w pełni zintegrowane z infrastrukturą PL-Grid umożliwiając polskiemu środowisku naukowemu, dzięki dziedzinowym rozwiązaniom portalowym, intuicyjny i łatwy dostęp do zasobów polskiego gridu obliczeniowego.
Obecnie poprzez usługi QosCosGrid możliwy jest dostęp do zasobów następujących ośrodków obliczeniowych wchodzących w skład infrastruktury projektu PL-Grid:
Nazwy klastrów obliczeniowych w poszczególnych ośrodkach do podania w opisie eksperymentu przy zlecaniu go do wykonania w konkretnym ośrodku.
Ośrodek | Klaser | Nazwa QCG |
---|---|---|
PCSS | reef | reef.man.poznan.pl |
PCSS | inula | inula.man.poznan.pl |
WCSS | supernova | nova.wcss.wroc.pl |
Cyfronet AGH | zeus | zeus.cyfronet.pl |
CI TASK | galera plus | galera.task.gda.pl |
ICM | hydra | hydra.icm.edu.pl |
Aby móc skorzystać z infrastruktury QosCosGrid należy:
Aby móc skorzystać z zasobów projektu PL-Grid z wykorzystaniem usług dostępowych QosCosGrid konieczne jest wystąpienie o dostęp do infrastruktury QosCosGrid poprzez wykonanie prostej sekwencji kroków opisanych poniżej.
Punkt pierwszy nie dotyczy zarejestrowanych użytkowników PL-Gridu.
Punkt drugi nie dotyczy natomiast osób, które posiadają już odpowiedni certyfikat
Aby zostać użytkownikiem PL-Gridu należy zarejestrować się w Portalu PL-Grid. Opis procedury można znaleźć „Podręczniku użytkownika”, w rozdziale: Zakładanie konta w portalu PL-Grid
Do korzystania z zasobów projektu PL-Gridu wymagane jest posiadanie certyfikatu osobistego, który poświadcza tożsamość użytkownika.
Certyfikat taki mogą wystawić użytkownikom PL-Gridu dwa centra certyfikacji (ang. Certification Authority, CA):
Certyfikaty wystawiane przez Simple CA są łatwiejsze do uzyskania, jednak respektowane tylko w ramach infrastruktury PL-Grid. Tożsamość osoby będącej użytkownikiem PL-Gridu nie musi już być dodatkowo weryfikowana.
Certyfikaty podpisywane przez Polish Grid CA są trudniejsze do uzyskania, jednak mogą być respektowane także w infrastrukturze europejskiej, poza PL-Gridem. Tożsamość użytkownika PL-Grid musi być dodatkowo zweryfikowana przez jeden z Urzędów Rejestracji Polish Grid CA (ang. Registration Authority, RA).
Dokładny opis procedury znaleźć można w rozdziale: Aplikowanie o certyfikat.
Po uzyskaniu certyfikatu, kolejnym krokiem jest jego rejestracja w Portalu PL-Grid. Opis czynności można znaleźć w sekcji podręcznika: Rejestracja certyfikatu w przeglądarce.
Aby uzyskać dostęp do infrastruktury QosCosGrid należy aplikować o odpowiednią usługę za pośrednictwem Portalu. W sekcji Usługi globalne zakładki Moje konto znajduje się lista usług. Wybrać należy odnośnik Aplikuj o usługę widoczny przy pozycji Globalny dostęp QosCosGrid.
Dostęp do infrastruktury QCG możliwy jest z dowolnego komputera, na którym zainstalowany jest klient usługi QCG-Broker (będącej częścią infrastruktury QCG), służący do zlecania i kontrolowania zadań na poziomie całego gridu. Dla wygody użytkowników uruchomiona została maszyna dostępowa do infrastruktury QCG z zainstalowaną wersją klienta dla użytkowników PL-Grid.
Klient tekstowy do infrastruktury PL-Grid dostępny jest w dwóch wersjach:
Dla wygody użytkowników klient usługi QCG-Broker zainstalowany został na ogólnodostępnej (dla użytkowników infrastruktury QCG) maszynie.
Adres maszyny: qcg.man.poznan.pl
Typ dostępu: ssh
Użytkownik i hasło są takie same jak w portalu PL-Grid.
Jednocześnie, maszyna dostępowa QCG udostępnia przestrzeń dyskową poprzez protokół gridFTP. Przestrzeń ta może być wykorzystana zarówno do przechowywania plików wejściowych, jak i wyników eksperymentów.
Logowanie: ssh <plguser>@qcg.man.poznan.pl
np.
ssh plgpiontek@qcg.man.poznan.pl
Po zalogowaniu przed pierwszym użyciem klienta konieczna jest konfiguracja środowiska użytkownika zgodnie z wytycznymi opisanymi na maszynie dostępowej.
Przed użyciem klienta QCG konieczne jest ustawienie środowiska wykonawczego wykonując polecenie: module load qcg
module load qcg
Każdy eksperyment obliczeniowy, zlecany do wykonania na infrastrukturze QosCosGrid, musi być opisany przez dokument w formacie XML, zwany później „opisem zadania”. Infrastruktura QCG akceptuje opisy zadań wyrażone w:
QCG-JobProfile
zdefiniowanym formalnie przez schemat XML - QCG-JobProfile.JSDL
(Job Submission Description Language) z rozszerzeniem HPC Basic Profile
. QCG-Simple
- prosty opis w postaci pliku tekstowego, w którym każda linia może zawierać dyrektywę interpretowaną przez system QCG. Uproszczony opis przeznaczony jest do zlecania najczęściej wykonywanych zadań, nie oferuje jednak dostępu do całej funkcjonalności systemy (brak wsparcia dla kaskad zadań (ang. workflow) i zadań parametrycznych (ang. parameter sweep)).W opisie zadania możliwe jest użycie następujących zmiennych:
Zlecany plik jest plikiem tekstowym, który może zawierać dyrektywy infrastruktury QCG.
Dyrektywą jest każda linia zaczynająca się od ”#QCG”.
Jeżeli w pliku nie zdefiniowano dyrektywy ”executable
” ani ”application
” uruchamiany jest zlecany plik z opisem zadania.
queue - wybrana kolejka systemu kolejkowego.
#QCG queue=plgrid
note - krótka informacja o zadaniu.
#QCG note=moje pierwsze zadanie QCG
name - dyrektywa określająca nazwę zadania. Nazwa zadania pojawi się jako końcówka identyfikatora zadania.
#QCG name=nobel-experiment
output - lokalizacja gdzie ma być przegrane standardowe wyjście zadnia (stdout). Jeśli nie jest to lokalizacja gsiftp zakłada się, że jest ustalana względem katalogu, z którego zlecono zadanie.
#QCG output=gsiftp://qcg.man.poznan.pl//home/plgrid/plgpiontek/reef/outputs/${JOB_ID}.output #QCG output=output.txt
error - lokalizacja gdzie ma być przegrany standardowe wyjście błędów zadnia (stderr). Jeśli nie jest to lokalizacja gsiftp zakłada się, że jest ustalana względem katalogu, z którego zlecono zadanie.
#QCG error=gsiftp://qcg.man.poznan.pl//home/plgrid/plgpiontek/reef/errors/${JOB_ID}.error #QCG error=error.txt
input - lokalizacja skąd ma być wzięte standardowe wejście dla aplikacji (stdin). Jeśli nie jest to lokalizacja gsiftp zakłada się, że jest ustalana względem katalogu, z którego zlecono zadanie.
#QCG input=gsiftp://qcg.man.poznan.pl//home/plgrid/plgpiontek/reef/inputs/experiment.input #QCG input=input.txt
host - nazwa maszyny na której może być uruchomione zadanie. Może być wiele takich dyrektyw dla alternatywnych maszyn.
#QCG host=reef.man.poznan.pl #QCG host=zeus.cyfronet.pl
W przypadku braku drugiego parametru plik kopiowany jest pod nazwę źródlową.
#QCG stage-in-file=gsiftp://qcg.man.poznan.pl//home/plgrid/plgpiontek/reef/inputs/input.txt -> input.txt #QCG stage-in-file=gsiftp://qcg.man.poznan.pl//home/plgrid/plgpiontek/reef/inputs/input.txt #QCG stage-in-file=input_file.txt -> input.txt #QCG stage-in-file=input_file.txt
stage-in-dir - dyrektywa kopiowania katalogu wejściowego. Funkcjonalność i składnia analogiczna jak dla dyrektywy „stage-in-file” tyle, że kopiowany jest katalog.
#QCG stage-in-dir=gsiftp://qcg.man.poznan.pl//home/plgrid/plgpiontek/reef/inputs -> inputs #QCG stage-in-dir=gsiftp://qcg.man.poznan.pl//home/plgrid/plgpiontek/reef/inputs #QCG stage-in-dir=input_dir -> inputs #QCG stage-in-dir=input_dir
Skopiowanie całego katalogu w którym uruchomiony został klient odbywa się poprzez podanie ”.” (kropki) jako nazwy katalogu źródłowego i ewentualnie docelowego
#QCG stage-in-dir=. -> . #QCG stage-in-dir=. #QCG stage-in-dir=. -> input
stage-out-file - dyrektywa kopiowania pliku wyjściowego. Składnia „nazwa_pliku_źródłowego → lokalizacja docelowa pliku”. Lokalizacja docelowa może być lokalizacją gsiftp lub ścieżką do pliku. W tym drugim przypadku zakłada się, że jest ustalana względem katalogu, z którego zlecono zadanie. W przypadku braku drugiego parametry plik przegrywany jest pod nazwę źródłową.
#QCG stage-out-file=results.txt -> gsiftp://qcg.man.poznan.pl//home/plgrid/plgpiontek/reef/results/result.1 #QCG stage-out-file=results.txt #QCG stage-out-file=result.txt -> ${JOB_ID}.result #QCG stage-out-file=result.txt
stage-out-dir - dyrektywa kopiowania katalogu wyjściowego. Funkcjonalność i składnia analogiczna jak dla dyrektywy „stage-out-file” tyle, że kopiowany jest katalog.
#QCG stage-out-dir=results -> gsiftp://qcg.man.poznan.pl//home/plgrid/plgpiontek/reef/results/${JOB_ID} #QCG stage-out-dir=results -> gsiftp://qcg.man.poznan.pl//home/plgrid/plgpiontek/reef/results/${JOB_ID} #QCG stage-out-dir=results -> result #QCG stage-out-dir=results
Skopiowanie całego katalogu w którym wykonane było zadanie odbywa się poprzez podanie ”.” (kropki) jako nazwy katalogu źródłowego.
#QCG stage-out-dir=. -> . #QCG stage-out-dir=. #QCG stage-out-dir=. -> output
grant - nazwa grantu, w ramach którego ma być wykonane zadanie.
#QCG grant=plgpiontek_grant
argument - argument aplikacji w przypadku użycia dyrektywy „executable” lub „application”. Argument może wystąpić wielokrotnie. Każdy argument powinien być przekazany w osobnej dyrektywie. Argumenty do aplikacji przekazywane są w kolejności ich wystąpienia w pliku opisu
#QCG argument=arg1 #QCG argument=arg2
environment - ustawianie zmiennych środowiskowych. Składnia „nazwa → wartość”. Każda zmienna musli być ustawiana w osobnej linii.
#QCG environment=name -> piontek #QCG environment=location -> poznan
executable - lokalizacja pliku do uruchomienia. Lokalizacja może być lokalizacją gsiftp lub ścieżką do pliku. W tym drugim przypadku przyjmuje się, że jest ustalana względem katalogu, z którego zlecone zostało zadanie. Opcjonalnie możliwe jest podanie nazwy pod jaką ma być zapisany plik wykonywalny. W przypadku braku nazwy zapisywany jest pod oryginalna nazwą.
#QCG executable=gsiftp://qcg.man.poznan.pl//home/plgrid/plgpiontek/reef/executables/exec1 #QCG executable=executables/exec1 #QCG executable=executables/exec1 -> exec-file
application - nazwa aplikacji do uruchomienia.
#QCG application=namd
persistent - dyrektywa określająca że po zakończeniu zadania system ma pozostawić katalog roboczy, w którym wykonywane było zadanie.
#QCG persistent
notify - dyrektywa umożliwiająca podanie protokołu i adresu docelowego dla powiadomień o stanie zadania. Możliwe jest wysyłanie powiadomień mailem i xmpp (dawniej Jabber).
#QCG notify=mailto:piontek@man.poznan.pl #QCG notify=xmpp:tomasz.piontek@gmail.com
W przypadku checi otrzymywania powiadomień protokołem xmpp konieczne jest dodanie do kontaktów nadawcy: qcg-notification@plgrid.pl
procs - liczba rdzeni obliczeniowych, na których ma być wykonane zadanie. (Stosowane dla zadań MPI.)
#QCG procs=32
nodes - dyrektywa pozwalająca zdefiniować na ilu węzłach i rdzeniach w ramach węzła ma być uruchomione zadanie. Opcjonalnie można podać ile procesów ma być uruchomione na węzłach. Domyślnie, jeżeli nie zostanie podane inaczej, liczna procesów równa jest liczbie rdzeni przydzielonych w ramach węzła. Składnia liczna_węzłów:liczba_rdzeni_na_węźleliczba_procesów.
#QCG nodes=10:5:1 #QCG nodes=12:12
#QCG walltime=P3DT12H
memory - dyrektywa definiująca deklarowane maksymalne zapotrzebowanie aplikacji na pamięć operacyjną. Podana wartość jest w MB.
#QCG memory=1024
properties - dyrektywa definiująca właściwości węzłów na których ma być uruchomione zadanie.
#QCG properties=mpi,ib,lustre
preprocess - dyrektywa umożliwiająca wykonanie polecenia/skryptu przed uruchomieniem właściwego zadania. Wartością dyrektywy może być polecenie lub ścieżka do pliku, który ma być wykonany.
#QCG preprocess=mkdir outputs
#QCG preprocess=preprocess-script.sh
postprocess - dyrektywa umożliwiająca wykonanie polecenia/skryptu po zakończeniu się właściwego zadania. Wartością dyrektywy może być polecenie lub ścieżka do pliku, który ma być wykonany.
#QCG postprocess=tar cvf wynik.tar *
#QCG preprocess=postprocess-script.sh
monitor - dyrektywa umożliwiająca zdefiniowanie skryptu, który zostanie uruchomiony przed uruchomieniem właściwego zadania i zabity po zakończeniu zadania. Funkcjonalność ta umożliwia w prosty sposób zaimplementowanie monitoringu aplikacji. Uruchomiony skrypt może cyklicznie wyszukiwać w wyniku aplikacji zadanych wzorców i przesyłać je w dowony sposób do użytkownika.
#QCG monitor=monitor-script.sh
module - dyrektywa umożliwiająca zdefiniowanie wymaganego przez zadanie modułu (nazwy programu/biblioteki oraz wersji). Możliwe jest wielokrotne podanie dyrektywy. Przy wyborze klastra do uruchomienia zadania system weźmie pod uwagę tylko te klastry na których dostępne są wszystkie wymagane moduły.
#QCG module=nwchem/6.0 #QCG module=namd
reservation - dyrektywa umożliwiająca podanie lokalnego identyfikatora rezerwacji w ramach której ma być wykonane zadanie. Użycie tej dyrektywy wymaga jednoznacznego podania hosta na którym jest założona podana rezerwacja.
#QCG host=reef.man.poznan.pl #QCG reservation=piontek.0
use-reservation - bezparametrowa dyrektywa umożliwiająca zdefiniowanie, ze dane zadanie ma być uruchomione z wykorzystaniem mechanizmu rezerwacji zasobów z wyprzedzeniem. Dyrektywa wymaga podania czasu wykonania zadania (dyrektywa #QCG walltime). Stosowanie tej dyrektywy pozwala „wymusić” rezerwacje, gdy nie były użyte dyrektywy „not-after”, „not-before”, „deadaline”. Dyrektywa wyklucza użycie równocześnie z dyrektywą „reservation”.
#QCG use-reservation #QCG walltime=PT2H
not-before - dyrektywa umożliwiająca zdefiniowanie, że zadanie ma być wykonane „nie wcześniej niż”. Argumentem dyrektywy jest data z opcjonalnym czasem. Dyrektywa wymusza użycie mechanizmu rezerwacji zasobów z wyprzedzeniem. Nie może być użyta równocześnie z dyrektywą „reservation”. W przypadku braku dyrektywy przyjmuje się, że zadanie może być uruchomione „od razu”. Dyrektywa wymaga dyrektywy „walltime”.
#QCG not-before=2012.07.25 #QCG walltime=PT2H
#QCG not-before=2012.07.25 15:20 #QCG walltime=PT2H
not-after - dyrektywa umożliwiająca zdefiniowanie, że zadanie ma być wykonane „nie później niż”. Argumentem dyrektywy jest data z opcjonalnym czasem. Dyrektywa wymusza użycie mechanizmu rezerwacji zasobów z wyprzedzeniem. Nie może być użyta równocześnie z dyrektywą „reservation”, wymaga podania dyrektywy „walltime”.
#QCG not-after=2012.08.25 #QCG walltime=PT2H
#QCG not-after=2012.08.25 13:20 #QCG walltime=PT2H
W przypadku nie podania dyrektywy „not_before” system próbuje dokonać rezerwacji zasobów od aktualnej chwili. Dyrektywa wyklucza równoczesne użycie „not_after”.
#QCG deadline=P3DT12H
#QCG not-before=2012.07.25 #QCG deadline=P3DT12H
Przykład dla PBSa oznaczający dane zadanie jako wznawialne.
(-r y|n Declares whether the job is rerunable.)
#QCG native=-r n
Uruchomienie na klastrze galera aplikacji „gaussian”.
#QCG queue=plgrid-long #QCG name=etanal #QCG note=etanal Gaussian #QCG output=${JOB_ID}.output #QCG error=${JOB_ID}.error #QCG stage-in-file=etanal.gjf -> etanal.gjf #QCG stage-out-file=wynik.tar -> ${JOB_ID}.tar #QCG nodes=1:12 #QCG host=galera.task.gda.pl #QCG persistent #QCG walltime=P7D #QCG notify=mailto:piontek@man.poznan.pl #QCG memory=15360 #QCG preprocess=echo START #QCG application=g09 #QCG argument=etanal.gjf #QCG postprocess=tar cvf wynik.tar *
przesłaniu pliku output.tgz do katalogu, z którego wykonano polecenie qcg-sub pod tę samą nazwę.
#!/bin/bash #QCG queue=plgrid #QCG persistent #QCG host=reef.man.poznan.pl #QCG output=output #QCG error=error #QCG stage-in-dir=inputs -> inputs /bin/tar -czf output.tgz inputs/input.* #QCG stage-out-file=output.tgz -> output.tgz
QCG-JobProfile jest XMLowym językiem opisu zadań QCG umożliwiającym dostęp do całej funkcjonalności oferowanej przez usługi QCG.
Język opisu zadań QCG składa się z następujących elementów:
Opis każdego eksperymentu obliczeniowego QCG rozpoczyna się elementem qcgJob W elemencie tym można podać następujące atrybuty:
commitWait- atrybut określający czy przetwarzanie eksperymentu ma być wstrzymane do czasu aż użytkownik wywoła polecenie commit_job (opcjonalny, dopuszczalne wartości: true,false, wartość domyślna: false),
<qcgJob appId="moj_eksperyment" project="grant123" commitWait="true"> ... </qcgJob>
Każdy eksperyment obliczeniowy składa się z minimum jednego zadania - elementu task o unikalnym identyfikatorze.
<qcgJob appId="moj_eksperyment" project="grant123" commitWait="true"> <task taskId="zadanie_1"> ... </task> <task taskId="zadanie_2"> ... </task> </qcgJob>
Eksperyment może zawierać opisujący go opcjonalny element description.
<qcgJob appId="moj_eksperyment"> <description>Najważniejszy eksperyment w PL-Grid<description> </qcgJob>
Element task odpowiada pojedynczemu zadaniu obliczeniowemu wchodzącemu w skład eksperymentu (qcgJob).
Task może/musi zawierać następujące atrybuty:
<qcgJob appId="moj_eksperyment"> ... <task taskId="zadanie_2" persistent="true" commitWait="false"> ... </task>
Zadanie może zawierać opisujący go opcjonalny element description.
<task taskId="zadanie_2" persistent="true" commitWait="false"> <description>Zadanie wyznaczające ...</description> </task>
Zlecając eksperyment do wykonania można dla każdego zadnia zdefiniować listę potencjalnych maszyn, spośród których QCG-Broker będzie dokonywał wyboru. W przypadku braku elementu candidateHosts Broker wybiera spośród wszystkich dostępnych maszyn, na których użytkownik ma prawo wykonywać zadania.
<candidateHosts> <hostName>reef.man.poznan.pl</hostName> <hostName>zeus.cyfronet.pl</hostName> </candidateHosts>
Element ten pozwala na wyrażenie wymagań zasobowych dotyczących zleconego zadania. Możliwe jest zdefiniowanie prostych wymagań opisujące tylko parametry węzłów obliczeniowych (element resourceRequirements) lub, w przypadku zadań rozproszonych, topologii i wymagań dla poszczególnych grup procesów (element topology).
Element zawierający opis wymagań zasobowych dotyczący parametrów maszyny obliczeniowej. Element ten może zawierać jeden lub więcej elementów computingResource ze zdefiniowaną listą parametrów - elementy hostParameter. Element hostParameter ma atrybut computingParameterName określający po nazwie definiowany parametr. Wartość parametru może być liczbowa, przekazywana w elemencie value, lub tekstowa w elemencie stringValue.
Lista możliwych parametrów:
<requirements> <resourceRequirements> <computingResource> <hostParameter name="gcpucount"> <value>3</value> </hostParameter> </computingResource> </resourceRequirements> </requirements>
<requirements> <resourceRequirements> <computingResource> <hostParameter name="queue"> <stringValue value="plgrid-long"/> </hostParameter> </computingResource> </resourceRequirements> </requirements>
<requirements> <resourceRequirements> <computingResource> <hostParameter name="application"> <stringValue value="abinit"/> </hostParameter> </computingResource> </resourceRequirements> </requirements>
Element topology służy do opisu zadań rozproszonych składających się z potencjalnie wielu grup procesów o odmiennych wymaganiach zasobowych.
W przypadku zadań z wieloma grupami procesów, lub przy podziale grupy pomiędzy wiele zasobów, QCG-Broker dokonuje koalokacji zasobów dla wszystkich grup.
Element topology zawiera nie mniej niż jeden element processes definiujący pojedynczą grupę procesów.
Element processes ma następujące atrybuty:
resourceRequirements - opis wymagań zasobowych dla grupy procesów,
<topology> <processes processesId="SMC:collector:distributor:Blob:voxelizer:thrombusMapper" masterGroup="true"> <processesCount> <value>1</value> </processesCount> <candidateHosts> <hostName>reef.man.poznan.pl</hostName> </candidateHosts> </processes> <processes processesId="BF"> <processesCount> <value>32</value> </processesCount> <candidateHosts> <hostName>huygens.sara.nl</hostName> </candidateHosts> <reservation type="LOCAL">p6012.huygens.sara.nl.537.r</reservation> </processes> <processes processesId="DD"> <processesCount> <value>4</value> </processesCount> <candidateHosts> <hostName>zeus.cyfronet.pl</hostName> </candidateHosts> </processes> </topology>
W poniższym przykładzie zadanie uruchomione zostanie na 3 węzłach (liczba elementów processesPerNode), na każdym węźle do zadania przydzielone zostanie 8 slotów obliczeniowych (atrybut slotsPerNode). Na węzłach uruchomione zostaną odpowiednio 1, 8, 8 procesów (wartości elementu processesPerNode).
<topology> <processes processesId="process"> <processesMap slotsPerNode="8"> <processesPerNode>1</processesPerNode> <processesPerNode>8</processesPerNode> <processesPerNode>8</processesPerNode> </processesMap> <candidateHosts> <hostName>grass1.man.poznan.pl</hostName> </candidateHosts> </processes> </topology>
Element execution opisuje uruchomienie pojedynczego zadania. Zawiera informację jaki jest jego typ, plik wykonywalny, argumenty, strumienie wejścia, wyjścia i błędów, pliki i katalogi z danymi wejściowymi i wynikami oraz zmienne środowiskowe. Atrybut type określa rodzaj zadania oraz sposób w jaki będzie wykonywane. Wspierane są następujące typy:
<execution type="single"> ... </execution>
Element określający aplikację oraz jej wersję (element application) lub plik wykonywalny (element execFile) dla danego zadania.
<executable> <application name="abinit" version="6.10.1"/> </executable>
<executable> <execFile> <file> <location type="URL">file:////usr/bin/cal</location> </file> </execFile> </executable>
<executable> <execFile> <file> <location type="URL">gsiftp://qcg.man.poznan.pl/~/executable</location> </file> </execFile> </executable>
Lista argumentów dla uruchomienia aplikacji. Każdy argument powinien być podany jako osobna wartość.
<arguments> <value>argument_1</value> <value>argument_2</value> <value>argument_3</value> </arguments>
Element stdin umożliwia przypisanie pliku do standardowego wejścia procesu. Element stdin musi zawierać lokalizację pojedynczego pliku. Wspierane są następujące typy lokalizacji:
REFERENCE - logiczna referencja do innego pliku w eksperymencie typu workflow.
<stdin> <file> <location type="URL">gsiftp://qcg.man.poznan.pl/~/experiments/stdin.txt</location> </file> </stdin>
<stdin> <file> <location type="REFERENCE">ref1</location> </file> </stdin>
Element stdout pozwala zdefiniować, gdzie powinno zostać przegrane standardowe wyjście aplikacji. Plik ten przegrywany jest jednokrotnie po zakończeniu wykonywania aplikacji. Element stdout może zawierać lokalizację pojedynczego pliku (element file), lub w przypadku aplikacji rozproszonej wykonującej się na wielu zasobach lokalizację katalogu (element directory), do którego przegrane zostaną pliki ze standardowym wyjściem z każdej alokacji.
Wspierane są następujące typy lokalizacji:
REFERENCE - logiczna referencja do innego pliku w eksperymencie typu workflow.
<stdout> <file> <location type="URL">gsiftp://qcg.man.poznan.pl/~/experiments/stdout.txt</location> </file> </stdout>
<stdout> <directory> <location type="URL">gsiftp://qcg.man.poznan.pl/~/experiments/stdouts</location> </directory> </stdout>
<stdout> <file> <location type="REFERENCE">ref1</location> </file> </stdout>
Element stderr pozwala zdefiniować, gdzie powinno zostać przegrane standardowe wyjście błędów aplikacji. Plik ten przegrywany jest jednokrotnie po zakończeniu wykonywania aplikacji. Element stderr może zawierać lokalizację pojedynczego pliku (element file), lub w przypadku aplikacji rozproszonej wykonującej się na wielu zasobach lokalizację katalogu (element directory), do którego przegrane zostaną pliki ze standardowym wyjściem błędu z każdej alokacji.
Wspierane są następujące typy lokalizacji:
REFERENCE - logiczna referencja do innego pliku w eksperymencie typu workflow.
<stderr> <file> <location type="URL">gsiftp://qcg.man.poznan.pl/~/experiments/stdout.txt</location> </file> </stderr>
<stderr> <directory> <location type="URL">gsiftp://qcg.man.poznan.pl/~/experiments/stdouts</location> </directory> </stderr>
<stderr> <file> <location type="REFERENCE">ref1</location> </file> </stderr>
Element stdInOut umożliwia zarządzanie danymi (plikami i katalogami) wejściowymi i wyjściowymi aplikacji. Element ten musi zawierać co najmniej jeden element opisujący plik (element file) lub katalog (element directory). Elementy file i directory muszą zawierać lokalizacje odpowiednio pojedynczego pliku lub katalogu i mają następujący zbiór atrybutów:
TASK_ID - identyfikator zadania.
<stageInOut> <file name="date.out" type="out" creationFlag="APPEND" permissions="644"> <location type="URL">gsiftp://fury.man.poznan.pl/~/examples/dates</location> </file> </stageInOut>
<stageInOut> <file name="input" type="in"> <location type="URL">gsiftp://qcg.man.poznan.pl/~/plgrid/staging/input.txt</location> </file> <file name="output.tar" type="out"> <location type="URL">gsiftp://qcg.man.poznan.pl/~/plgrid/output/output-${JOB_ID}.tar</location> </file> <directory name="results" type="out"> <location type="URL">gsiftp://qcg.man.poznan.pl/~/plgrid/output/output-${JOB_ID}-${TASK_ID}.tar</location> </directory> </stageInOut>
<stageInOut> <file name="ps" type="in"> <location type="REFERENCE">ref1</location> </file> <file name="ps.tgz" type="out"> <location type="URL">gsiftp://qcg.reef.man.poznan.pl/ps.tgz</location> </file> </stageInOut>
Lista zmiennych środowiskowych i ich wartości, które przekazane zostaną przy uruchomieniu zadania
<environment> <variable name="PATH">/home/piontek</variable> <variable name="VERBOSE">true</variable> </environment>
Element reservation pozwala zdefiniować rezerwację, do której ma być zlecone zadanie.
Element posiada atrybuty:
Element executionTime pozwala zdefiniować wymagania czasowe dla zadania. Element ten musi zawierać element executionDuration definiujący długość czasu obliczeń oraz opcjonalnie element timePeriod określający okno czasowe, w którym zadanie ma być wykonane. Element timePeriod musi zawierać element periodStart określający początek okna czasowego oraz periodEnd (koniec okna) lub periodDuration (długość okna czasowego).
<executionTime> <executionDuration>P0Y0M0DT0H30M</executionDuration> </executionTime>
<executionTime> <executionDuration>P0Y0M0DT24H0M</executionDuration> <timePeriod> <periodStart>2011-11-23T14:29:00</periodStart> <periodEnd>2011-11-24T18:29:00</periodEnd> </timePeriod> </executionTime>
Element workflow pozwala definiować złożone zależności kolejnościowe pomiędzy zadaniami w eksperymencie. Dla każdego zadania możliwe jest zdefiniowanie od jakich innych zadań ono zależy, używając zagnieżdżonych warunków z wykorzystaniem operatorów AND/OR oraz dowolnych stanów zadań. Zależności pomiędzy zadaniami nie mogą zawierać cykli. Element workflow może zawierać jeden z następujących elementów:
or - logiczny operator OR pozwalający tworzyć złożone warunki. Element or może zawierać elementy parent, and i or.
<workflow> <parent>task_1</parent> </workflow>
<workflow> <parent triggerState="FINISHED">task_2</parent> </workflow>
<workflow> <and> <parent triggerState="FINISHED">task_1</parent> <parent triggerState="RUNNING">task_2</parent> </and> </workflow>
<workflow> <or> <parent triggerState="FINISHED">task_1</parent> <parent triggerState="RUNNING">task_2</parent> </or> </workflow>
<workflow> <or> <parent triggerState="FINISHED">task_1</parent> <and> <parent triggerState="FINISHED">task_2</parent> <parent triggerState="FINISHED">task_3</parent> </and> </or> </workflow>
Element parameterSweep służy do definiowania zadań parametrycznych, to znaczy takich, w których ta sama aplikacja uruchamiana jest wielokrotnie dla różnych parametrów. QCG-Broker umożliwia definiowanie wielowymiarowej przestrzeni parametrów, w której jednocześnie wg podanych reguł może zmienianych być wiele parametrów. Możliwe jest definiowanie różnych schematów zmienności parametrów (kolejności zmieniania wartości wielu parametrów) jak również zakresów zmienności pojedynczych elementów. Element parameterSweep musi zawierać co najmniej jeden element parameter definiujący zmienność pojedynczego parametru. Element parameter zawiera następujące elementy:
set - zmiana parametru ze zdefinowanego zbioru wartości.
<parametersSweep> <parameter> <name>arg1</name> <value> <loop> <start>0</start> <end>9</end> <step>1</step> <except> <value>3</value> <value>6</value> </except> </loop> </value> </parameter> </parametersSweep>
task | arg1 |
---|---|
task_1 | 1 |
task_2 | 2 |
task_3 | 3 |
task_4 | 4 |
task_5 | 5 |
task_6 | 6 |
task_7 | 7 |
task_8 | 8 |
task_9 | 9 |
<parametersSweep> <parameter> <name>arg2</name> <value> <set> <item>a</item> <item>b</item> </set> </value> </parameter> </parametersSweep>
task | arg2 |
---|---|
task_1 | a |
task_2 | b |
<parametersSweep> <parameter> <name>arg1</name> <value> <loop> <start>0</start> <end>5</end> <step>1</step> <except> <value>3</value> <value>4</value> </except> </loop> </value> </parameter> <parameter> <name>arg2</name> <value> <set> <item>a</item> <item>b</item> </set> </value> </parameter> </parametersSweep>
task | arg1 | arg2 |
---|---|---|
task_1 | 0 | a |
task_2 | 1 | b |
task_3 | 2 | a |
task_4 | 5 | b |
<parametersSweep> <parameter> <name>arg1</name> <value> <loop> <start>0</start> <end>5</end> <step>1</step> <except> <value>3</value> <value>4</value> </except> </loop> </value> <parameter> <name>arg2</name> <value> <set> <item>a</item> <item>b</item> </set> </value> </parameter> </parameter> </parametersSweep>
task | arg1 | arg2 |
---|---|---|
task_1 | 0 | a |
task_2 | 0 | b |
task_3 | 1 | a |
task_4 | 1 | b |
task_5 | 2 | a |
task_6 | 2 | b |
task_7 | 5 | a |
task_8 | 5 | b |
EKSPERYMENT: Pobranie pliku report, spakowanie go aplikacją tar i przegranie wyniku do podanej lokalizacji. Zadanie wykonane zostanie na klastrze reef.man.poznan.pl. Standardowe strumienie wyjścia przegrane zostaną do podanych lokalizacji.
<grmsJob appId="eksperyment"> <task taskId="tar"> <candidateHosts> <hostName>reef.man.poznan.pl</hostName> </candidateHosts> <execution type="single"> <executable> <execFile> <file> <location type="URL">file:////bin/tar</location> </file> </execFile> </executable> <arguments> <value>cfv</value> <value>report.tar</value> <value>report</value> </arguments> <stdout> <file> <location type="URL">gsiftp://qcg.man.poznan.pl/~stdout-${JOB_ID}</location> </file> </stdout> <stderr> <file> <location type="URL">gsiftp://qcg.man.poznan.pl/~/stderr-${JOB_ID}</location> </file> </stderr> <stageInOut> <file name="report" type="in"> <location type="URL">gsiftp://fury.man.poznan.pl/~/examples/report</location> </file> <file name="report.tar" type="out"> <location type="URL">gsiftp://fury.man.poznan.pl/~/examples/report.tar</location> </file> </stageInOut> </execution> </task> </grmsJob>
Eksperyment: Wykonanie zbioru zadań „calc” dla miesięcy roku 2012 z pominięciem miesięcy 3 i 6. Standardowe lokalizacje przegrane zostaną do podanej lokalizacji.
<grmsJob appId="kalendarze"> <task taskId="calendar"> <execution type="single"> <executable> <execFile> <file> <location type="URL">file:////usr/bin/cal</location> </file> </execFile> </executable> <arguments> <value>${PS_month}</value> <value>2012</value> </arguments> <stdout> <file> <location type="URL">${TASK_DIR}/stdout.txt</location> </file> </stdout> </execution> <parametersSweep> <parameter> <name>month</name> <value> <loop> <start>1</start> <end>12</end> <step>1</step> <except> <value>3</value> <value>6</value> </except> </loop> </value> </parameter> </parametersSweep> </task> </grmsJob>
Eksperyment: Prosty workflow składający się z dwóch zadań (aplikacja date). Drugie zadanie wykonane będzie po zakończeniu pierwszego. Strumienie wyjściowe przegrane zostaną do podanych lokalizacji.
<qcgJob appId="example1"> <task taskId="date_1"> <execution type="single"> <executable> <execFile> <file> <location type="URL">file:////bin/date</location> </file> </execFile> </executable> <stdout> <file> <location type="URL">gsiftp://qcg.man.poznan.pl/~/date-${JOB_ID}-${TASK_ID}.txt</location> </file> </stdout> </execution> </task> <task taskId="date_2"> <execution type="single"> <executable> <execFile> <file> <location type="URL">file:////bin/date</location> </file> </execFile> </executable> <stdout> <file> <location type="URL">gsiftp://qcg.man.poznan.pl/~/date-${JOB_ID}-${TASK_ID}.txt</location> </file> </stdout> </execution> <workflow> <parent triggerState="FINISHED">date_1</parent> </workflow> </task> </qcgJob>
Eksperyment: Prosty workflow, w którym drugie zadanie „pakuje” wyjście polecenia „ps” w pierwszego zadania. Plik przekazywane są „przez” referencje.
<qcgJob appId="ps_tar"> <task taskId="ps"> <execution type="single"> <executable> <execFile> <file> <location type="URL">file:////bin/ps</location> </file> </execFile> </executable> <arguments> <value>aux</value> </arguments> <stdout> <file> <location type="REFERENCE">ref1</location> </file> </stdout> </execution> </task> <task taskId="tar"> <execution type="single"> <executable> <execFile> <file> <location type="URL">file:////bin/tar</location> </file> </execFile> </executable> <arguments> <value>czf</value> <value>ps.tgz</value> <value>ps</value> </arguments> <stageInOut> <file name="ps" type="in"> <location type="REFERENCE">ref1</location> </file> <file name="ps.tgz" type="out"> <location type="URL">gsiftp://qcg.reef.man.poznan.pl/ps.tgz</location> </file> </stageInOut> </execution> <workflow> <parent triggerState="FINISHED">ps</parent> </workflow> </task> </qcgJob>
QCG-SimpleClient oferuje prosty, wzorowany na poleceniech systemu kolejkowego, interfejs do infrastruktury QCG.
plik_z_opisem
qcg-sub /home/piontek/tasks/date.qcg qcg-sub ./tasks/date.qcg
czas_jednostka [stan,[stan]]
qcg-list qcg-list 7d qcg-list 1m qcg-list 7d finished qcg-list 1m finished,failed
Dla wygody użytkowników zamiast listy stanów możliwe jest podanie zdefiniowanych stałych:
qcg-list 7d all qcg-list 7d terminated qcg-list 7d unterminated
jobId pokaz_opis
qcg-info J1331196390748_date_3099 true
jobId liczba_znaków
qcg-peek J1331196390748_date_3099 qcg-peek J1331196390748_date_3099 10
qcg-proxy
jobId
qcg-cancel J1331196390748_date_3099
jobId
qcg-clean J1331196390748_date_3099
qcg-interactive /home/piontek/tasks/bash.qcg qcg-interactive ./tasks/bash.qcg
#QCG host=inula.man.poznan.pl /bin/bash
W opisie zadania interaktywnego można korzystać również z innych dyrektyw QCG celem podania np. wymagań zasobowych dla zadania interaktywnego.
jobId
qcg-refetch J1331196390748_date_3099
[qcg] /home/plgrid/plgpiontek/reef/SANDBOX > qcg-sub ./date.qcg UserDN = /C=PL/O=GRID/O=PSNC/CN=Tomasz Piontek ProxyLifetime = 0 Days 7 Hours 26 Minutes 28 Seconds jobId = J1333024407992__5066
[qcg] /home/plgrid/plgpiontek/reef/SANDBOX > qcg-list 1h UserDN = /C=PL/O=GRID/O=PSNC/CN=Tomasz Piontek ProxyLifetime = 0 Days 7 Hours 25 Minutes 40 Seconds Number of tasks: 1 JOB IDENTIFIER TASK NOTE SUBMISSION TIME FINISH TIME STATUS STATUS DESCRIPTION HOSTNAME J1333024407992__5066 task example 2012.03.29 14:33 RUNNING nova.wcss.wroc.pl
[qcg] /home/plgrid/plgpiontek/reef/SANDBOX > qcg-list 1d UserDN = /C=PL/O=GRID/O=PSNC/CN=Tomasz Piontek ProxyLifetime = 0 Days 7 Hours 25 Minutes 21 Seconds Number of tasks: 11 JOB IDENTIFIER TASK NOTE SUBMISSION TIME FINISH TIME STATUS STATUS DESCRIPTION HOSTNAME J1333024407992__5066 task example 2012.03.29 14:33 2012.03.29 14:34 FINISHED nova.wcss.wroc.pl J1333011075468__2453 task 2012.03.29 10:51 RUNNING reef.man.poznan.pl J1333009151247__1761 task 2012.03.29 10:19 2012.03.29 10:34 CANCELED Subtask from host 'r reef.man.poznan.pl J1333008447161__5525 task 2012.03.29 10:07 2012.03.29 10:07 FAILED Subtask from host 'g grass.man.poznan.pl
[qcg] /home/plgrid/plgpiontek/reef/SANDBOX > qcg-list 1d running UserDN = /C=PL/O=GRID/O=PSNC/CN=Tomasz Piontek ProxyLifetime = 0 Days 7 Hours 22 Minutes 59 Seconds Number of tasks: 1 JOB IDENTIFIER TASK NOTE SUBMISSION TIME FINISH TIME STATUS STATUS DESCRIPTION HOSTNAME J1333011075468__2453 task 2012.03.29 10:51 RUNNING reef.man.poznan.pl
[qcg] /home/plgrid/plgpiontek/reef/SANDBOX > qcg-info J1333024407992__5066 UserDN = /C=PL/O=GRID/O=PSNC/CN=Tomasz Piontek ProxyLifetime = 0 Days 7 Hours 21 Minutes 25 Seconds Note: example TaskType: SINGLE SubmissionTime: Thu Mar 29 14:33:28 CEST 2012 FinishTime: Thu Mar 29 14:34:31 CEST 2012 ProxyLifetime: PT0S Status: FINISHED StatusDesc: StartTime: Thu Mar 29 14:33:28 CEST 2012 Allocation: HostName: nova.wcss.wroc.pl ProcessesCount: 1 ProcessesGroupId: Status: FINISHED StatusDescription: SubmissionTime: Thu Mar 29 14:33:28 CEST 2012 FinishTime: Thu Mar 29 14:34:31 CEST 2012 LocalSubmissionTime: Thu Mar 29 14:33:29 CEST 2012 LocalStartTime: Thu Mar 29 14:33:49 CEST 2012 LocalFinishTime: Thu Mar 29 14:34:30 CEST 2012
[qcg] /home/plgrid/plgpiontek/reef/SANDBOX > qcg-info J1333024407992__5066 true UserDN = /C=PL/O=GRID/O=PSNC/CN=Tomasz Piontek ProxyLifetime = 0 Days 7 Hours 20 Minutes 7 Seconds Note: example TaskType: SINGLE SubmissionTime: Thu Mar 29 14:33:28 CEST 2012 FinishTime: Thu Mar 29 14:34:31 CEST 2012 ProxyLifetime: PT0S Status: FINISHED StatusDesc: StartTime: Thu Mar 29 14:33:28 CEST 2012 DescriptionType: <task persistent="true" taskId="task"> <note>example</note> <execution type="single"> <executable> <execFile> <file name="execFile"> <location type="URL">gsiftp://qcg.man.poznan.pl:2811//home/plgrid/plgpiontek/reef/SANDBOX/./date.qcg</location> </file> </execFile> </executable> <stdout> <file> <location type="URL">gsiftp://qcg.man.poznan.pl:2811//home/plgrid/plgpiontek/reef/SANDBOX/output</location> </file> </stdout> </execution> </task> Allocation: HostName: nova.wcss.wroc.pl ProcessesCount: 1 ProcessesGroupId: Status: FINISHED StatusDescription: SubmissionTime: Thu Mar 29 14:33:28 CEST 2012 FinishTime: Thu Mar 29 14:34:31 CEST 2012 LocalSubmissionTime: Thu Mar 29 14:33:29 CEST 2012 LocalStartTime: Thu Mar 29 14:33:49 CEST 2012 LocalFinishTime: Thu Mar 29 14:34:30 CEST 2012
[qcg] /home/plgrid/plgpiontek/reef/SANDBOX > qcg-peek J1333024407992__5066 /C=PL/O=GRID/O=PSNC/CN=qcg-broker/qcg-broker.man.poznan.pl UserDN = /C=PL/O=GRID/O=PSNC/CN=Tomasz Piontek ProxyLifetime = 0 Days 7 Hours 16 Minutes 47 Seconds Thu Mar 29 14:33:44 CEST 2012
[qcg] /home/plgrid/plgpiontek/reef/SANDBOX > qcg-proxy https://elder7.man.poznan.pl:8443/qcg/services/ /C=PL/O=GRID/O=PSNC/CN=qcg-broker/qcg-broker.man.poznan.pl UserDN = /C=PL/O=GRID/O=PSNC/CN=Tomasz Piontek ProxyLifetime = 0 Days 11 Hours 59 Minutes 52 Seconds Your identity: C=PL,O=GRID,O=PSNC,CN=Tomasz Piontek Enter GRID pass phrase for this identity: Creating proxy, please wait... Proxy verify OK Your proxy is valid until Fri Mar 30 02:49:53 CEST 2012
[qcg] /home/plgrid/plgpiontek/reef/SANDBOX > qcg-cancel J1333011075468__2453 https://elder7.man.poznan.pl:8443/qcg/services/ /C=PL/O=GRID/O=PSNC/CN=qcg-broker/qcg-broker.man.poznan.pl UserDN = /C=PL/O=GRID/O=PSNC/CN=Tomasz Piontek ProxyLifetime = 0 Days 11 Hours 58 Minutes 18 Seconds
[qcg] /home/plgrid/plgpiontek/reef/SANDBOX > qcg-cancel J1333011075468__2453 https://elder7.man.poznan.pl:8443/qcg/services/ /C=PL/O=GRID/O=PSNC/CN=qcg-broker/qcg-broker.man.poznan.pl UserDN = /C=PL/O=GRID/O=PSNC/CN=Tomasz Piontek ProxyLifetime = 0 Days 11 Hours 57 Minutes 49 Seconds ErrorCode = 133 ErrorMessage = Job in status (CANCELED) can't be canceled
Klient QCG może być uruchomiony w dwóch trybach:
Schemat użycia klient zależy od wybranego trybu:
Do uwierzytelnienia i delegacji uprawnień użytkownika klient wymaga poprawnej konfiguracji i dostępu do certyfikatu proxy użytkownika.
Niezależnie od trybu klient infrastruktury QCG wspiera następujące polecenia:
Polecenie | Argumenty | Opis |
---|---|---|
submit_job | <plik_z_opisem> [QCG lub JSDL] | Zleca eksperyment obliczeniowy do wykonania na infrastrukturze QCG. Opis zadania może być wyrażony albo przy pomocy domyślnego języka QCG, albo przy użyciu języka JSDL (Job Submission Description Language) z rozszerzeniem HPC Basic Profile. W przypadku opisu w języku JSDL format opisu (JSDL) musi być jawnie podany jako parametr wywołania. Jeżeli opis jest składniowo i logicznie poprawny zwracany jest globalnie unikalny identyfikator zadania. QCG definiuje eksperymenty obliczeniowe (ang. job) jako zbiór zadań (ang. task) z zależnościami kolejnościowymi (ang. workflow). QCG wspiera zarówno proste zadnia jak również zadania parametryczne (ang. parameter sweep) czy zadania rozproszone (w tym zadania hybrydowe MPI/OpenMP). Dla każdego zadania możliwe jest zdefiniowanie wymaganej przez nie jakości usług (ang. Quality of Service) dotyczącej zarówno charakterystyki zasobów jak i czasu wykonania. |
list_jobs | [<limit>] [<status>] | Wyświetla listę eksperymentów obliczeniowych należących do danego `użytkownika`. Możliwe jest ograniczenie listy do zadanej liczby ostatnich eksperymentów i/lub eksperymentów o określonym statusie. Lista wszystkich możliwych statusów z ich znaczeniami zebrana została pod poniższą tabelą. |
list_user_jobs | <użytkownik> [<limit>] [<status>] | Wyświetla listę eksperymentów należącą do podanego użytkownika. Polecenie to ma charakter administracyjny i wymaga określonych uprawnień |
test_description | <plik_z_opisem> [QCG lub JSDL] | Waliduje (czyli sprawdza poprawność składniową) opis eksperymentu obliczeniowego |
translate_description | <plik_z_opisem> JSDL | Tłumaczy opis zadania z formatu JSDL do formatu QCG |
job_info | <jobId> [<pokażOpis>] | Wyświetla pełną informację o podanym eksperymencie obliczeniowym. Jeżeli `pokażOpis` ma wartość `true` opis eksperymentu jest wyświetlany. |
cancel_job | <jobId> | Anuluje lub przerywa wykonywanie eksperymentu obliczeniowego. |
commit_job | <jobId> | Zatwierdza do wykonania eksperyment zlecony z opcja commitWait=true . Mechanizm ten umożliwia zarejestrowanie notyfikacji zanim rozpocznie się przetwarzanie eksperymentu. |
list_tasks | <jobId> [<status>] | Wyświetla listę zadań wchodzących w skład eksperymentu. Opcjonalnie możliwe jest ograniczenie listy do zadań o konkretnym statusie. Lista wszystkich możliwych statusów z ich znaczeniami zebrana została pod poniższą tabelą. |
tasks_statuses | <jobId> [<podsumowanie>]` | Wyświetla listę zadań należących do danego eksperymentu wraz z ich statusami. Jeżeli argument `podsumowanie` ma wartość `true` dodatkowa statystyka jest wyświetlana. |
register_job_notification | <jobId> <url> | Rejestruje odbiorcę powiadomień dla danego eksperymentu. |
list_job_notifications | <jobId> | Wyświetla listę zarejestrowanych powiadomień dla danego eksperymentu |
register_tasks_notification | <jobId> <url> | Rejestruje odbiorcę powiadomień dla wszystkich zadań danego eksperymentu. |
monitor_job | <jobId> [<odstęp>] | Monitoruje zmiany statusów zadań należących do danego eksperymentu. Argument `odstęp` określa odstęp w sekundach pomiędzy kolejnymi sprawdzeniami. |
monitor_task | <jobId> <taskId> [<odstęp>] | Monitoruje zmiany statusów alokacji należących do danego zadania. Argument `odstęp` określa odstęp w sekundach pomiędzy kolejnymi sprawdzeniami. |
task_info | <jobId> <taskId> [<pokażOpis> | Wyświetla informację o danym zadaniu. Jeżeli argument `pokażOpis` ma wartość `true` to opis zadania jest wyświetlany. |
register_task_notification | <jobId> <taskId> <url> | Rejestruje odbiorcę powiadomień dla danego zadania. |
list_task_notifications | <jobId> <taskId> | Wyświetla listę zarejestrowanych powiadomień dla danego zadania |
cancel_task | <jobId> <taskId> | Anuluje lub przerywa wykonywanie danego zadania. |
commit_task | <jobId> <taskId> | Zatwierdza do wykonania zadanie zlecone z opcja commitWait=true . Mechanizm ten umożliwia zarejestrowanie notyfikacji zanim rozpocznie się przetwarzanie zadania. |
create_reservation | <job_desc> (QCG or JSDL) | Rezerwuje zasoby spełniające wymagania eksperymentu. Zwracany jest identyfikator rezerwacji. |
reservation_info | <reservationId> | Zwraca informację dotyczącą danej rezerwacji: listę zarezerwowanych zasobów, lokalnych identyfikatorów rezerwacji, czas rezerwacji. |
cancel_reservation | <reservationId> | Zwalnia zarezerwowane zasoby. |
help | [wzorzec] | Wyświetla pomoc dla poleceń klienta QCG. Opcjonalnie możliwe jest podanie wzorca wyszukiwania. |
proxy_init | Tworzy certyfikat proxy użytkownika. | |
proxy_info | Wyświetla informację o certyfikacie proxy użytkownika. |
Polecenie | Argumenty | Opis |
---|---|---|
history | [limit] [wzorzec] | Wyświetla historię poleceń klienta. Możliwe jest ograniczenie liczby poleceń i/lub podanie wzorca wyszukiwań dla polecań. |
quite | Zakończenie pracy klienta w trybie konsoli. | |
file | plik | Wyświetla zawartość pliku tekstowego |
clear | Czyści wyjście konsoli | |
alias | [klucz] [wartość] | Polecenie służące do zarządzania aliasami. Wywołane bez parametrów wyświetla listę zdefiniowanych aliasów. Wywołane z parametrem klucz wyświetla dla niego wartość o ile została ona zdefiniowana. Wywołane z parametrami klucz, wartość definiuje nowy, lub zastępuje stary alias. |
unalias | klucz [klucz]* | Usuwa definicja aliasu, lub listy aliasów |
proxy_reload | Odświeża certyfikat proxy użytkownika używany przez klienta QCG. |
commitWait
i oczekuje na zatwierdzenie,[qcg] /home/plgrid/plgpiontek/reef > qcg-client -console https://elder7.man.poznan.pl:8443/qcg/services/ /C=PL/O=GRID/O=PSNC/CN=qcg-broker/qcg-broker.man.poznan.pl Your identity: C=PL,O=GRID,O=PSNC,CN=Tomasz Piontek Enter GRID pass phrase for this identity: Creating proxy, please wait... Proxy verify OK Your proxy is valid until Thu Dec 08 10:48:39 CET 2011 UserDN = /C=PL/O=GRID/O=PSNC/CN=Tomasz Piontek ProxyLifetime = 0 Days 11 Hours 59 Minutes 59 Seconds qcg>
qcg> submit_job ./plgrid/sites/reef.xml jobId = J1323294704605_reef_test_3932 qcg>
qcg> job_info $$ Command translated to: job_info J1323294704605_reef_test_3932 UserDN: /C=PL/O=GRID/O=PSNC/CN=Tomasz Piontek Project: Status: FINISHED StatusDesc: SubmissionTime: Wed Dec 07 22:51:44 CET 2011 FinishTime: Wed Dec 07 22:52:52 CET 2011 Number of tasks: 1 Tasks: date qcg>
\- $$ jest aliasem ostatnio zleconego zadania
qcg> job_info $$ true Command translated to: job_info J1323294704605_reef_test_3932 true UserDN: /C=PL/O=GRID/O=PSNC/CN=Tomasz Piontek Project: Status: FINISHED StatusDesc: SubmissionTime: Wed Dec 07 22:51:44 CET 2011 FinishTime: Wed Dec 07 22:52:52 CET 2011 Number of tasks: 1 Tasks: date DescriptionType: QCG UserDescription: <qcgJob appId="reef_test"> <task taskId="date"> <candidateHosts> <hostName>reef.man.poznan.pl</hostName> </candidateHosts> <execution type="single"> <executable> <execFile> <file> <location type="URL">file:////bin/date</location> </file> </execFile> </executable> </execution> </task> </qcgJob> QCGDescription: <qcgJob appId="reef_test"> <task taskId="date"> <candidateHosts> <hostName>reef.man.poznan.pl</hostName> </candidateHosts> <execution type="single"> <executable> <execFile> <file> <location type="URL">file:////bin/date</location> </file> </execFile> </executable> </execution> </task> </qcgJob>
qcg> task_info $$ date Command translated to: task_info J1323294704605_reef_test_3932 date TaskType: SINGLE SubmissionTime: Wed Dec 07 22:51:44 CET 2011 FinishTime: Wed Dec 07 22:52:52 CET 2011 ProxyLifetime: PT0S Status: FINISHED StatusDesc: StartTime: Wed Dec 07 22:52:23 CET 2011 Allocation: UserDN: /C=PL/O=GRID/O=PSNC/CN=Tomasz Piontek HostName: qcg.reef.man.poznan.pl ProcessesCount: 1 ProcessesGroupId: Status: FINISHED StatusDescription: SubmissionTime: Wed Dec 07 22:52:22 CET 2011 FinishTime: Wed Dec 07 22:52:51 CET 2011 LocalSubmissionTime: Wed Dec 07 22:52:45 CET 2011 LocalStartTime: Wed Dec 07 22:52:51 CET 2011 LocalFinishTime: Wed Dec 07 22:52:51 CET 2011
qcg> task_info $$ date true Command translated to: task_info J1323294704605_reef_test_3932 date true TaskType: SINGLE SubmissionTime: Wed Dec 07 22:51:44 CET 2011 FinishTime: Wed Dec 07 22:52:52 CET 2011 ProxyLifetime: PT0S Status: FINISHED StatusDesc: StartTime: Wed Dec 07 22:52:23 CET 2011 DescriptionType: <task taskId="date"> <candidateHosts> <hostName>reef.man.poznan.pl</hostName> </candidateHosts> <execution type="single"> <executable> <execFile> <file> <location type="URL">file:////bin/date</location> </file> </execFile> </executable> </execution> </task> Allocation: UserDN: /C=PL/O=GRID/O=PSNC/CN=Tomasz Piontek HostName: qcg.reef.man.poznan.pl ProcessesCount: 1 ProcessesGroupId: Status: FINISHED StatusDescription: SubmissionTime: Wed Dec 07 22:52:22 CET 2011 FinishTime: Wed Dec 07 22:52:51 CET 2011 LocalSubmissionTime: Wed Dec 07 22:52:45 CET 2011 LocalStartTime: Wed Dec 07 22:52:51 CET 2011 LocalFinishTime: Wed Dec 07 22:52:51 CET 2011
qcg> list_jobs Number of jobs: 20 List of jobs: J1321877662165_MAPPER_3300 J1321881875958_MAPPER_9672 J1321911256889_MAPPER_8420 J1321914854440_dir_sara_0689 J1321914906334_dir_sara_2043 J1321915056747_dir_sara_9032 J1321916113112_MAPPER_1960 J1321961392495_staging_test_1449 J1321963242870_staging_test_5150 J1321981394174_queue_4615 J1321983740521_queue_5194 J1321983825887_queue_0285 J1321990965100_MAPPER_4312 J1322035696224_dir_sara_5146 J1322035933283_reef_test_1178 J1322129087052_reef_test_4725 J1322129109259_reef_test_7586 J1322129140743_reef_test_5658 J1323211002163_example1_4389 J1323294704605_reef_test_3932
qcg> list_jobs 5 Number of jobs: 5 List of jobs: J1322129087052_reef_test_4725 J1322129109259_reef_test_7586 J1322129140743_reef_test_5658 J1323211002163_example1_4389 J1323294704605_reef_test_3932
qcg> list_jobs canceled Number of jobs: 3 List of jobs: J1321911256889_MAPPER_8420 J1321914906334_dir_sara_2043 J1321990965100_MAPPER_4312
------ JobMonitor -------- JobID: J1323294704605_reef_test_3932 Number of tasks: 1 UNCOMMITTED : 0 UNSUBMITTED : 0 QUEUED : 0 PREPROCESSING : 0 PENDING : 0 RUNNING : 0 STOPPED : 0 POSTPROCESSING : 0 BROKEN : 0 CANCELED : 0 FAILED : 0 FINISHED : 1 Press ESC to break
------ TasksMonitor -------- JobID: J1323294704605_reef_test_3932 Number of tasks: 1 date : FINISHED ( qcg.reef.man.poznan.pl ) Press ESC to break
------ TaskMonitor -------- JobID: J1323294704605_reef_test_3932 TaskID: date Status: FINISHED Number of allocations: 1 Host: qcg.reef.man.poznan.pl ProcessesCount: 1 GroupID: null Status: FINISHED Press ESC to break
qcg> tasks_statuses $$ Command translated to: tasks_statuses J1323294704605_reef_test_3932 Number of tasks: 1 Tasks statuses: date : FINISHED ------ SUMMARY -------- Number of tasks: 1 FINISHED : 1 qcg>
qcg> cancel_job $$ Command translated to: cancel_job J1323294704605_reef_test_3932 ErrorCode = 133 ErrorMessage = Job in status (FINISHED) can't be canceled
qcg> file ./tests/rezerwacje/reservation.xml <qcgJob appId="RESERVATION"> <task persistent="true" taskId="reserve"> <requirements> <topology> <processes processesId="reef"> <processesCount> <value>1</value> </processesCount> <candidateHosts> <hostName>reef.man.poznan.pl</hostName> </candidateHosts> </processes> <processes processesId="nova"> <processesCount> <value>1</value> </processesCount> <candidateHosts> <hostName>nova.wcss.wroc.pl</hostName> </candidateHosts> </processes> </topology> </requirements> <executionTime> <executionDuration>P0Y0M0DT0H10M</executionDuration> </executionTime> </task> </qcgJob>
qcg> create_reservation ./tests/rezerwacje/reservation.xml reservationId = R1323347194781_RESERVATION_7460
qcg> list_reservations 5 Number of reserations: 5 List of reservations: R1323346041037_RESERVATION_0324 R1323346137384_RESERVATION_8804 R1323346963809_RESERVATION_9107 R1323347051808_RESERVATION_5725 R1323347194781_RESERVATION_7460
qcg> reservation_info $$ Command translated to: reservation_info R1323347194781_RESERVATION_7460 UserDN: /C=PL/O=GRID/O=PSNC/CN=Tomasz Piontek SubmissionTime: Thu Dec 08 13:26:34 CET 2011 StartTime: Thu Dec 08 13:29:00 CET 2011 EndTime: Thu Dec 08 13:40:00 CET 2011 Status: ACTIVE TotalSlotsCount: 2 InUse: false HostName: reef.man.poznan.pl ProcessesGroupId: reef SlotsCount: 1 LocalReservationId: plgpiontek.0 Node: r127 SlotsCount: 1 HostName: nova.wcss.proc.pl ProcessesGroupId: nova SlotsCount: 1 LocalReservationId: R2258372.nova Node: wn382 SlotsCount: 1
qcg> cancel_reservation $$ Command translated to: cancel_reservation R1323347194781_RESERVATION_7460
QCG-Icon jest lekką aplikacją dostępną na platformy Windows, MAC OSX oraz Linux mająca na celu udostępnianie wybranych aplikacji zainstalowanych na zasobach obliczeniowych projektu PL-Grid poprzez usługi QosCosGrid. Przy tworzeniu aplikacji położono szczególny nacisk na to by korzystanie aplikacji zainstalowanej „w Gridzie” było tak intuicyjne jak korzystanie z aplikacji zainstalowanych lokalnie. W obecnej wersji aplikacji możliwe jest uruchamianie sumulacji Gaussian, NAMD oraz skryptów napisanych w języku MATLAB, R i BASH. Lista wspieranych aplikacji nieustannie rośnie.
Więcej informacji na stronie domowej projektu lub w podręczniku użytkownika.
Środowisko portalowe dla naukowców z dziedziny nanotechnologii – Nanotechnology Gateway. Aktualna wersja zintegrowana jest z aplikacjami ABINIT, Quantum Espresso oraz NAMD i NW-Chem a jej podstawową funkcjonalnością jest przygotowywanie danych wejściowych, zlecanie zadań do rozproszonych systemów komputerowych, monitorowanie stanu i kontrolowanie symulacji, przetwarzanie i analiza rezultatów, przechowywanie i archiwizacja danych. Oprócz tego dostępne są w pełni zautomatyzowane operacje na danych, jak ich przenoszenie, konwersja, przetwarzanie oraz wizualizacja. Najbardziej zaawansowaną częścią portalu jest klient aplikacji ABINIT. Pakiet oprogramowania do symulacji ABINIT pozwala między innymi na rozwiązywanie następujących problemów: wyznaczanie energii całkowitej, gęstości ładunkowych oraz struktury elektronowej układów kwantowo-mechanicznych (elektrony, jądra atomowe) w oparciu o założenia teorii funkcjonału gęstości (pseudopotencjały oraz bazę fal płaskich).
Kontakt: contact@qoscosgrid.org
Zgłaszanie problemów: http://helpdesk.plgrid.pl
Lista dyskusyjna: support@lists.qoscosgrid.org