Section | ||||
---|---|---|---|---|
|
Table of Contents | ||||
---|---|---|---|---|
|
Usugi QCG tworzone są w ramach projektu PL Grid PLUS przez grupę progrmistów z Poznańskiego Centrum Suprkomputerowo-Sieciowego.
...
Obecnie poprzez usługi QosCosGrid możliwy jest Usługi i narzędzia QosCosGrid oferują dostęp do wszystkich zasobów następujących ośrodków obliczeniowych (kastrów) wchodzących w skład infrastruktury projektu PL-Grid:
Info |
---|
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 |
.
Szczegółowe informacje o dostępnych zasobach znajdują się na stronie:zasoby obliczeniowe dostępne przez QosCosGrid.
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:
...
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:
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 |
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>
|
...
Zlecanie i kontrolowanie zadań w infrastrukturze PL-Grid odbywać się może w zależności od preferencji i przyzwyczajeń użytkownika z wykorzystaniem różnych klientów. Podstawowymi narzędziami dostępowymi są klient tekstowy (QCG-SimpleClient) oraz narzędzie graficzne (QCG-Now). Przegląd dostępnych klientów znajduje się na stronie: narzędzia dostępowe QosCosGrid.
Narzędzia i usługi QosCosGrid rozwijane są przez zespół programistów z Poznańskiego Centrum Superkomputerowo Sieciowego. |
---|
Kontakt: qcg@plgrid.pl
Zgłaszanie problemów: http://helpdesk.plgrid.pl