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.
Unikalna funkcjonalność usług QCG:
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 |
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 czy po zakończeniu zadania system ma pozostawić katalog roboczy, w którym wykonywane było zadanie.
#QCG persistent
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
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>