...
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.
Info |
---|
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.
Code Block |
---|
ssh plgpiontek@qcg.man.poznan.pl |
Info |
---|
Po zalogowaniu przed pierwszym użyciem klienta konieczna jest konfiguracja środowiska użytkownika zgodnie z wytycznymi opisanymi na maszynie dostępowej. |
Info |
---|
Przed użyciem klienta QCG konieczne jest ustawienie środowiska wykonawczego wykonując polecenie: module load qcg |
Code Block |
---|
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”.
Info |
---|
Jeżeli w pliku nie zdefiniowano dyrektywy ” |
queue - wybrana kolejka systemu kolejkowego.
Code Block |
---|
#QCG queue=plgrid |
note - krótka informacja o zadaniu.
Code Block |
---|
#QCG note=moje pierwsze zadanie QCG |
name - dyrektywa określająca nazwę zadania. Nazwa zadania pojawi się jako końcówka identyfikatora zadania.
Code Block |
---|
#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.
Code Block |
---|
#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.
Code Block |
---|
#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.
Code Block |
---|
#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.
Code Block |
---|
#QCG host=reef.man.poznan.pl #QCG host=zeus.cyfronet.pl |
W przypadku braku drugiego parametru plik kopiowany jest pod nazwę źródlową.
Code Block |
---|
#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.
Code Block |
---|
#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 |
Info |
---|
Skopiowanie całego katalogu w którym uruchomiony został klient odbywa się poprzez podanie ”.” (kropki) jako nazwy katalogu źródłowego i ewentualnie docelowego |
Code Block |
---|
#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ą.
Code Block |
---|
#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.
Code Block |
---|
#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 |
Info |
---|
Skopiowanie całego katalogu w którym wykonane było zadanie odbywa się poprzez podanie ”.” (kropki) jako nazwy katalogu źródłowego. |
Code Block |
---|
#QCG stage-out-dir=. -> . #QCG stage-out-dir=. #QCG stage-out-dir=. -> output |
grant - nazwa grantu, w ramach którego ma być wykonane zadanie.
Code Block |
---|
#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
Code Block |
---|
#QCG argument=arg1 #QCG argument=arg2 |
environment - ustawianie zmiennych środowiskowych. Składnia „nazwa → wartość”. Każda zmienna musli być ustawiana w osobnej linii.
Code Block |
---|
#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ą.
Code Block |
---|
#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.
Code Block |
---|
#QCG application=namd |
persistent - dyrektywa określająca czy po zakończeniu zadania system ma pozostawić katalog roboczy, w którym wykonywane było zadanie.
Code Block |
---|
#QCG persistent |
procs - liczba rdzeni obliczeniowych, na których ma być wykonane zadanie. (Stosowane dla zadań MPI.)
Code Block |
---|
#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.
Code Block |
---|
#QCG nodes=10:5:1 #QCG nodes=12:12 |
Code Block |
---|
#QCG walltime=P3DT12H |
memory - dyrektywa definiująca deklarowane maksymalne zapotrzebowanie aplikacji na pamięć operacyjną. Podana wartość jest w MB.
Code Block |
---|
#QCG memory=1024 |
properties - dyrektywa definiująca właściwości węzłów na których ma być uruchomione zadanie.
Code Block |
---|
#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.
Code Block |
---|
#QCG preprocess=mkdir outputs |
Code Block |
---|
#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.
Code Block |
---|
#QCG postprocess=tar cvf wynik.tar * |
Code Block |
---|
#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.
Code Block |
---|
#QCG monitor=monitor-script.sh |
Uruchomienie na klastrze galera aplikacji „gaussian”.
Code Block |
---|
#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ę.
Code Block |
---|
#!/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),
Code Block |
---|
<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.
Code Block |
---|
<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.
Code Block |
---|
<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:
Code Block |
---|
<qcgJob appId="moj_eksperyment"> ... <task taskId="zadanie_2" persistent="true" commitWait="false"> ... </task> |
Zadanie może zawierać opisujący go opcjonalny element description.
Code Block |
---|
<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.
Code Block |
---|
<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:
Code Block |
---|
<requirements> <resourceRequirements> <computingResource> <hostParameter name="gcpucount"> <value>3</value> </hostParameter> </computingResource> </resourceRequirements> </requirements> |
Code Block |
---|
<requirements> <resourceRequirements> <computingResource> <hostParameter name="queue"> <stringValue value="plgrid-long"/> </hostParameter> </computingResource> </resourceRequirements> </requirements> |
Code Block |
---|
<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,
Code Block |
---|
<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).
Code Block |
---|
<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:
Code Block |
---|
<execution type="single"> ... </execution> |
Element określający aplikację oraz jej wersję (element application) lub plik wykonywalny (element execFile) dla danego zadania.
Code Block |
---|
<executable> <application name="abinit" version="6.10.1"/> </executable> |
Code Block |
---|
<executable> <execFile> <file> <location type="URL">file:////usr/bin/cal</location> </file> </execFile> </executable> |
Code Block |
---|
<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ść.
Code Block |
---|
<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.
Code Block |
---|
<stdin> <file> <location type="URL">gsiftp://qcg.man.poznan.pl/~/experiments/stdin.txt</location> </file> </stdin> |
Code Block |
---|
<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.
Code Block |
---|
<stdout> <file> <location type="URL">gsiftp://qcg.man.poznan.pl/~/experiments/stdout.txt</location> </file> </stdout> |
Code Block |
---|
<stdout> <directory> <location type="URL">gsiftp://qcg.man.poznan.pl/~/experiments/stdouts</location> </directory> </stdout> |
Code Block |
---|
<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.
Code Block |
---|
<stderr> <file> <location type="URL">gsiftp://qcg.man.poznan.pl/~/experiments/stdout.txt</location> </file> </stderr> |
Code Block |
---|
<stderr> <directory> <location type="URL">gsiftp://qcg.man.poznan.pl/~/experiments/stdouts</location> </directory> </stderr> |
Code Block |
---|
<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.
Code Block |
---|
<stageInOut> <file name="date.out" type="out" creationFlag="APPEND" permissions="644"> <location type="URL">gsiftp://fury.man.poznan.pl/~/examples/dates</location> </file> </stageInOut> |
Code Block |
---|
<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> |
Code Block |
---|
<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
Code Block |
---|
<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).
Code Block |
---|
<executionTime> <executionDuration>P0Y0M0DT0H30M</executionDuration> </executionTime> |
Code Block |
---|
<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.
Code Block |
---|
<workflow> <parent>task_1</parent> </workflow> |
Code Block |
---|
<workflow> <parent triggerState="FINISHED">task_2</parent> </workflow> |
Code Block |
---|
<workflow> <and> <parent triggerState="FINISHED">task_1</parent> <parent triggerState="RUNNING">task_2</parent> </and> </workflow> |
Code Block |
---|
<workflow> <or> <parent triggerState="FINISHED">task_1</parent> <parent triggerState="RUNNING">task_2</parent> </or> </workflow> |
Code Block |
---|
<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.
Code Block |
---|
<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 |
Code Block |
---|
<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 |
Code Block |
---|
<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 |
Code Block |
---|
<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.
Code Block |
---|
<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.
Code Block |
---|
<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.
Code Block |
---|
<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.
Code Block |
---|
<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
- ścieżka do pliku z uproszczonym opisem zadaniaCode Block |
---|
qcg-sub /home/piontek/tasks/date.qcg qcg-sub ./tasks/date.qcg |
\[liczba jednostka\] \[stan,\[stan\]\]
- lista zadań. Opcjonalnie można podać z jakiego czasu mają być zadania - z ostatnich „liczba” dni („d”), godzin („h”), minut („m”). Drugim opcjonalnym parametrem jest lista stanów zadań oddzielonych przecinkami (bez spacji). W przypadku niepodania stanów wyświetlane są zadania niezakończone.Code Block |
---|
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:
Code Block |
---|
qcg-list 7d all qcg-list 7d terminated qcg-list 7d unterminated |
jobId pokaz_opis
- jobId - identyfikator eksperymentu. Jeśli pokaz_opis ma wartość „true” to dodatkowo wyświetlany jest opis zadnia. Domyślną wartością jest „false”.Code Block |
---|
qcg-info J1331196390748_date_3099 true |
jobId \[liczba_znaków\]
- jobId - identyfikator eksperymentu, liczba_znaków - liczba znaków do wyświetlenia,Code Block |
---|
qcg-peek J1331196390748_date_3099 qcg-peek J1331196390748_date_3099 10 |
Code Block |
---|
qcg-proxy |
jobId
- identyfikator eksperymentuCode Block |
---|
qcg-cancel J1331196390748_date_3099 |
Code Block |
---|
[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 |
Code Block |
---|
[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 |
Code Block |
---|
[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 |
Code Block |
---|
[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 |
Code Block |
---|
[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 |
Code Block |
---|
[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 |
Code Block |
---|
[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 |
Code Block |
---|
[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 |
Code Block |
---|
[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 |
Code Block |
---|
[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:
Info |
---|
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,Code Block |
---|
[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> |
Code Block |
---|
qcg> submit_job ./plgrid/sites/reef.xml
jobId = J1323294704605_reef_test_3932
qcg>
|
Code Block |
---|
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
Code Block |
---|
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>
|
Code Block |
---|
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
|
Code Block |
---|
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
|
Code Block |
---|
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
|
Code Block |
---|
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
|
Code Block |
---|
qcg> list_jobs canceled
Number of jobs: 3
List of jobs:
J1321911256889_MAPPER_8420
J1321914906334_dir_sara_2043
J1321990965100_MAPPER_4312
|
Code Block |
---|
------ 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
|
Code Block |
---|
------ TasksMonitor --------
JobID: J1323294704605_reef_test_3932
Number of tasks: 1
date : FINISHED ( qcg.reef.man.poznan.pl )
Press ESC to break
|
Code Block |
---|
------ 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
|
Code Block |
---|
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>
|
Code Block |
---|
qcg> cancel_job $$
Command translated to:
cancel_job J1323294704605_reef_test_3932
ErrorCode = 133
ErrorMessage = Job in status (FINISHED) can't be canceled
|
Code Block |
---|
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>
|
Code Block |
---|
qcg> create_reservation ./tests/rezerwacje/reservation.xml
reservationId = R1323347194781_RESERVATION_7460
|
Code Block |
---|
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
|
Code Block |
---|
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
|
Code Block |
---|
qcg> cancel_reservation $$
Command translated to:
cancel_reservation R1323347194781_RESERVATION_7460
|