Infrastruktura QosCosGrid
Section |
---|
Column |
---|
Image RemovedImage Added |
Column |
---|
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ść Zalety korzystania z usług
...
dostępowych QCG
- prostota i intuicyjność korzystania (polecenia qcg-*)
- prosty format opisu zadań,
- dostęp do wszystkich zasobów infrastruktury PL-Grid z jednego miejsca,
- nowatorska funkcjonalność,
- powiadamiania o stanie zadania poprzez pocztę (e-mail) lub z wykorzystaniem komunikatora (Jabber - protoków XMMP),
- stabilność,
- rozszerzalność.
- pełne wsparcie przez grupę twórców usług QCG.
Usugi QCG tworzone są w ramach projektu PL Grid PLUS przez grupę progrmistów z Poznańskiego Centrum Suprkomputerowo-Sieciowego.
Unikalna funkcjonalność usług QCG
- Wsparcie dla zadań interaktywnych.
- Możliwość "podłączania się" interaktywną sesją do wcześniej uruchomionych zadań.
- Gwarancja wymaganej jakości usług obliczeniowych (ang. Quality of Service), w
Logiczne scalanie zasobów obliczeniowych pochodzących z wielu klastrów w jeden rozproszony system obliczeniowy.
Skrócenie czasu oczekiwania na przydział zasobów oraz umożliwienie uruchamiania różnego typu zadań obliczeniowych o wymaganiach przekraczających możliwości pojedynczego klastra poprzez wykorzystanie (koalokację) wielu zasobów.
- Gwarancja wymaganej jakości usług obliczeniowych (ang. Quality of Service), w tym czasu wykonania zadania poprzez wykorzystanie zaawansowanych mechanizmów rezerwacji zasobów z wyprzedzeniem.
Możliwość rezerwowania zasobów obliczeniowych i uruchamiania zadań na wcześniej zarezerwowanych zasobach.
Logiczne scalanie zasobów obliczeniowych pochodzących z wielu klastrów w jeden rozproszony system obliczeniowy.
Skrócenie czasu oczekiwania na przydział zasobów oraz umożliwienie uruchamiania różnego typu zadań obliczeniowych o wymaganiach przekraczających możliwości pojedynczego klastra poprzez wykorzystanie (koalokację) wielu zasobów.
Możliwość rezerwowania zasobów obliczeniowych i uruchamiania zadań na wcześniej zarezerwowanych zasobach.
Integracja ze środowiskami uruchomieniowymi: OpenMPI, Integracja ze środowiskami uruchomieniowymi: OpenMPI, ProActive, Muscle.
Wsparcie dla zadań hybrydowych MPI/OpenMP.
Możliwość definiowania złożonych zależności kolejnościowych pomiędzy zadaniami w eksperymentach typu workflow (z użyciem operatorów AND/OR i dowolnych stanów zadań).
Możliwość definiowania zadań parametrycznych jako części eksperymentu typu workflow.
Dostępne zasoby
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.
Szczegółowe informacje o dostępnych zasobach znajdują się na stronie:
PCSS - Poznańskie Centrum Superkomputerowo Sieciowe - klaster reef
WCSS - Wrocławskie Centrum Sieciowo Superkomputerowe - klaster supernova
Cyfronet AGH - Akademickie Centrum Komputerowe Cyfronet AGH - klaster Zeus
CI TASK - Centrum Informatyczne Trójmiejskiej Akademickiej Sieci Komputerowej -klaster galera plus
ICM - Interdyscyplinarne Centrum Modelowania Matematycznego UW - klaster hydra.
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 |
PCSS | inula | inula.man.poznan.pl |
WCSS | supernova | nova.wcss.wroc.pl |
Cyfronet AGH | zeus | zeus.cyfronet.pl |
CI TASK | galera plus | galera.task.gda.pl |
ICM | hydra | hydra.icm.edu.pl |
Korzystanie z infrastruktury
Aby móc skorzystać z infrastruktury QosCosGrid należy:
skorzystać z wybranej metody dostępowej:
Aplikowanie o usługę
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.
Kolejność kroków
Info |
---|
Punkt pierwszy nie dotyczy zarejestrowanych użytkowników PL-Gridu. Punkt drugi nie dotyczy natomiast osób, które posiadają już odpowiedni certyfikat |
Wystąpienie o certyfikat użytkownika PL-Grid.
Aplikowanie o dostęp do infrastruktury QosCosGrid.
Po zaakceptowaniu Państwa zgłoszenia przez administratora usługi w ośrodku obliczeniowym wchodzącym w skład infrastruktury PL-Grid można zacząć korzystać z zasobów danego ośrodka wybierając dowolną metodę dostępową (klient tekstowy, graficzne narzędzia dla wybranych aplikacji).
1. Rejestracja
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
2. Wystąpienie o certyfikat
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.
3. Rejestracja certyfikatu w PL-Gridzie
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.
4. Aplikowanie o Globalny dostęp do infrastruktury QosCosGrid
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.
Image Removed
Klient tekstowy
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:
SimpleClient - zestaw prostych poleceń wzorowanych na poleceniach systemu kolejkowego, AdvancedClient - ogólny klient oferujący dostęp do całej funkcjonalności infrastruktury QCG.
Maszyna dostępowa QCG
...
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 |
Image Removed
Formaty opisu zadań
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:
Zmienne opisu zadania
W opisie zadania możliwe jest użycie następujących zmiennych:
HOSTNAME - nazwa hosta (klastra) na jakim uruchomione zostało zadanie,
HOME - katalog domowy użytkownika,
TASK_DIR - katalog roboczy zadania,
JOB_ID - identyfikator eksperymentu,
TASK_ID - identyfikator zadania,
USER_DN - DN (Distinguished Name) użytkownika (identyfikator użytkownika widoczny w certyfikacie, w formacie PEM, np. /C=PL/O=GRID/O=PSNC/CN=Tomasz Piontek)
PROCESS_GROUP - identyfikator grupy procesów.
QCG-Simple
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 ”executable ” ani ”application ” uruchamiany jest zlecany plik z opisem zadania. |
Lista dyrektyw
- application - aplikacja
- argument - argument aplikacji
- deadline- wykonaj w okresie czasu
- environment - zmienna środowiskowa
- error - standardowe wyjście błędów
- executable - plik wykonywalny
- grant - grant
- host - wybór klastra
- input - standardowe wejście
- memory - pamięć
- module- wymagany moduł
- monitor - skrypt monitorujący zadanie
- name - nazwa zadania
- native- specyficzne parametry/wymagania zasobowe przekazywane bezpośrednio do systemu kolejkowego
- nodes - topologia aplikacji
- not-after- nie później niż
- not-before- nie wcześniej niż
- note - opis zadania
- notify - powiadamianie o stanie zadania
- output - standardowe wyjście
- persistent - nieusuwanie katalogu roboczego zadania po jego zakończeniu
- postprocess - epilog zadania
- preprocess - prolog zadania
- procs - liczba procesów
- properties - parametry węzłów
- queue - wybór kolejki
- reservation- użycie rezerwacji z wyprzedzeniem
- stage-in-dir - katalog wejściowy
- stage-in-file - plik wejściowy
- stage-out-dir - katalog wynikowy
- stage-out-file - plik wynikowy
- use-reservation- użycie rezerwacji z wyprzedzeniem
- walltime - czas wykonania
queue
note
name
output
error
host
stage-in-file
- stage-in-file - dyrektywa kopiowania pliku wejściowego. Składnia „lokalizacja_źródłowa → nazwa_docelowa_pliku”. Lokalizacja źródłowa 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 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
stage-out-file
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
grant
argument
environment
executable
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
persistent
notify
notify - dyrektywa umożliwiająca podanie protokołu i adresu docelowego dla powiadomień o stanie zadania. Możliwe jest wysyłanie powiadomień mailem i xmpp (dawniej Jabber).
Code Block |
---|
#QCG notify=mailto:piontek@man.poznan.pl
#QCG notify=xmpp:tomasz.piontek@gmail.com |
W przypadku checi otrzymywania powiadomień protokołem xmpp konieczne jest dodanie do kontaktów nadawcy: qcg-notification@plgrid.pl
procs
nodes
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
|
walltime
- walltime - dyrektywa definiująca deklarowany przez użytkownika czas wykonania zadania w formacie PnYnMnDTnHnMnS, w formacie ISO 8601 gdzie:
- P - obowiązkowy znak rozpoczynający definicję okresu,
- nY - liczba lat,
- nM - liczba miesięcy,
- nD - liczba dni,
- T - separator czasu (musi być obecny, jeśli zdefiniowane są poniższe wartości)
- nH - liczba godzin,
- nM - liczba minut,
- nS - liczba sekund.
Code Block |
---|
#QCG walltime=P3DT12H |
memory
properties
preprocess
postprocess
monitor
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
|
module
reservation
use-reservation
use-reservation - bezparametrowa dyrektywa umożliwiająca zdefiniowanie, ze dane zadanie ma być uruchomione z wykorzystaniem mechanizmu rezerwacji zasobów z wyprzedzeniem. Dyrektywa wymaga podania czasu wykonania zadania (dyrektywa #QCG walltime). Stosowanie tej dyrektywy pozwala „wymusić” rezerwacje, gdy nie były użyte dyrektywy „not-after”, „not-before”, „deadaline”. Dyrektywa wyklucza użycie równocześnie z dyrektywą „reservation”.
Code Block |
---|
#QCG use-reservation
#QCG walltime=PT2H |
not-before
not-before - dyrektywa umożliwiająca zdefiniowanie, że zadanie ma być wykonane „nie wcześniej niż”. Argumentem dyrektywy jest data z opcjonalnym czasem. Dyrektywa wymusza użycie mechanizmu rezerwacji zasobów z wyprzedzeniem. Nie może być użyta równocześnie z dyrektywą „reservation”. W przypadku braku dyrektywy przyjmuje się, że zadanie może być uruchomione „od razu”. Dyrektywa wymaga dyrektywy „walltime”.
Code Block |
---|
#QCG not-before=2012.07.25
#QCG walltime=PT2H |
Code Block |
---|
#QCG not-before=2012.07.25 15:20
#QCG walltime=PT2H |
not-after
not-after - dyrektywa umożliwiająca zdefiniowanie, że zadanie ma być wykonane „nie później niż”. Argumentem dyrektywy jest data z opcjonalnym czasem. Dyrektywa wymusza użycie mechanizmu rezerwacji zasobów z wyprzedzeniem. Nie może być użyta równocześnie z dyrektywą „reservation”, wymaga podania dyrektywy „walltime”.
Code Block |
---|
#QCG not-after=2012.08.25
#QCG walltime=PT2H |
Code Block |
---|
#QCG not-after=2012.08.25 13:20
#QCG walltime=PT2H |
deadline
- deadline - dyrektywa umożliwiająca zdefiniowanie, że zadanie ma być wykonane „w czasie nie dłuższym niż”. Dyrektywa wymusza użycie mechanizmu rezerwacji zasobów z wyprzedzeniem. Nie może być użyta równocześnie z dyrektywą „reservation”. Argumentem dyrektywy jest przedział czasu w formacie PnYnMnDTnHnMnS (ISO 8601) gdzie:
- P - obowiązkowy znak rozpoczynający definicję okresu,
- nY - liczba lat,
- nM - liczba miesięcy,
- nD - liczba dni,
- T - separator czasu (musi być obecny, jeśli zdefiniowane są poniższe wartości)
- nH - liczba godzin,
- nM - liczba minut,
- nS - liczba sekund.
W przypadku nie podania dyrektywy „not_before” system próbuje dokonać rezerwacji zasobów od aktualnej chwili. Dyrektywa wyklucza równoczesne użycie „not_after”.
Code Block |
---|
#QCG deadline=P3DT12H |
Code Block |
---|
#QCG not-before=2012.07.25
#QCG deadline=P3DT12H |
native
- native - dyrektywa umożliwiająca przekazanie do systemu kolejkowego specyficznych dla niego wymagań zasobowych. Wymagania takie są specyficzne do systemu kolejkowego i powinny być używane z dyrektywami „host” i w przemyślany przez użytkownika sposób.
Przykład dla PBSa oznaczający dane zadanie jako wznawialne.
(-r y|n Declares whether the job is rerunable.)
Code Block |
---|
#QCG native=-r n |
Przykładowe opisy
QCG-JobProfile
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:
- qcgJob- element grupujący zadania w logiczny eksperyment
- description - opis eksperymentu obliczeniowego
- task- definicja pojedynczego zadania
qcgJob - definicja eksperymentu
Opis każdego eksperymentu obliczeniowego QCG rozpoczyna się elementem qcgJob W elemencie tym można podać następujące atrybuty:
- appId - definiowany przez użytkownika element, który pojawi się jako część identyfikatora eksperymentu. Dozwolone są znaki dopuszczalne w nazwach katalogów w systemie Linux (obowiązkowy, typ: tekst),
- project - identyfikator grantu, w ramach którego zlecany jest eksperyment (opcjonalny, typ: tekst),
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>
|
description - opis eksperymentu
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>
|
task - definicja zadania
Element task odpowiada pojedynczemu zadaniu obliczeniowemu wchodzącemu w skład eksperymentu (qcgJob).
Task może/musi zawierać następujące atrybuty:
- taskId - unikalny identyfikator zadania w ramach eksperymentu. Dozwolone są znaki dopuszczalne w nazwach katalogów w systemie Linux (obowiązkowy, typ: tekst)
- persistent - określa czy po zakończeniu zadania system ma automatycznie usunąć czy pozostawić katalog, w którym wykonywało się zadanie (opcjonalny, dopuszczalne wartości: true,false, wartość domyślna: false),
- crucial - określa czy poprawne zakończenie zadania jest istotne dla pomyślnego zakończenia całego eksperymentu (opcjonalny, dopuszczalne wartości: true,false, wartość domyślna: true),
- commitWait - atrybut określający czy przetwarzanie zadania ma być wstrzymane do czasu aż użytkownik wywoła polecenie commit_task (opcjonalny, dopuszczalne wartości: true,false, wartość domyślna: false),
Code Block |
---|
<qcgJob appId="moj_eksperyment">
...
<task taskId="zadanie_2" persistent="true" commitWait="false">
...
</task>
|
description - opis zadania
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>
|
candidateHosts - lista potencjalnych zasobów obliczeniowych
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>
|
requirements - definicja wymagań zasobowych dla zadania
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).
resourceRequirements - opis wymagań zasobowych
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:
- osname - nazwa systemu operacyjnego,
- ostype - typ systemu operacyjnego,
- cpuarch - architektura procesora
- cpucount - liczba procesorów
- gpucount - liczba akceleratorów graficznych
- application - dostępne aplikacje
- queue - nazwa kolejki, do której ma być zlecone zadanie
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>
|
topology - topologia grup procesów
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:
- processesId - identyfikator grupy procesów (opcjonalny, typ: tekst),
- masterGroup - atrybut ten pozwala określić, do której grupy należeć ma proces master rozproszonej aplikacji (opcjonalny, typ: logiczny, domyślnie false). W przypadku, gdy żadna grupa nie jest wybrana proces master wybierany jest niedeterministycznie,
- divisible - atrybut określający czy dana grupa może być dzielona pomiędzy wiele zasobów (opcjonalny, typ: logiczny, domyślna wartość: true),
Każdy element processes może zawierać następujące elementy: - processesCount - liczność grupy procesów,
- processesMap - mapa alokacji procesów dla zadań hybrydowych (określa liczbę węzłów obliczeniowych dla zadania oraz procesów na każdym z węzłów),
- candidateHosts - lista potencjalnych maszyn, na których może być wykonana grupa procesów,
- reservation - rezerwacja, w ramach której ma być uruchomiona grupa procesów. Element ten wymaga jednoznacznego wyboru maszyny poprzez candidateHosts,
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>
|
execution - deklaracja typu zadania
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:
- single - aplikacja będąca pojedynczym procesem,
- open_mpi, mpi_mp - zadanie rozproszone MPI. Zadanie może składać się z wielu alokacji, a stan zadania zależy od stanu wszystkich alokacji. Jeżeli element stdout/etderr wskazuje na katalog, to standardowe wyjścia zgrywane są ze wszystkich alokacji. Jeżeli element stdout/etderr wskazuje na plik, to standardowe wyjścia zgrywane jest tylko z procesu mastera. Pliki wyjściowe kopiowane są tylko z głównej alokacji (proces master). W przypadku, gdy jedna z alokacji zakończy się niepowodzeniem, wykonywanie pozostałych jest automatycznie anulowane. Ustawiane są następujące zmienne środowiskowe:
- OMPI_SESSION_ID - unikalny identyfikator sesji,
- OMPI_PROCESSES_ID - identyfikator grupy procesów,
- OMPI_MASTER_GROUP - informacja czy dana alokacja zawiera proces master,
- OMPI_PROCESSES - łaczna liczba procesów,
- OMPI_COLORS - opis kolorów dla zadania (procesy o tym samym kolorze znajdują się na tym samym zasobie),
- QCG_MACHINEFILE - lokalizacja pliku machinefile,
- mapper - zadanie rozproszone. Różni się od typu open_mpi tym, że pliki wyjściowe przegrywane są ze wszystkich alokacji. Dla tego typu zadnia przekazywane są następujące zmienne środowiskowe: OMPI_PROCESSES_ID, OMPI_MASTER_GROUP, OMPI_PROCESSES,
- proactive - zadanie rozproszone środowiska PROACTIVE. Różni się od zadania open_mpi tym, że do głównej alokacji kopiowany jest tworzony automatycznie plik proactive description. Do zadania przekazywane są następujące zmienne środowiskowe:
- PROACITIVE_SESSION_ID - identyfikator sesji, mający postać '{JOBID}:{TASKID}'
- PROACTIVE_PROCESSES_ID - identyfikator grupy procesów
- PROACTIVE_MASTER_GROUP - informacja czy dana alokacja zawiera proces master,
- PROACTIVE_PROCESSES - łączna liczba procesów.
Code Block |
---|
<execution type="single">
...
</execution>
|
executable - deklaracja aplikacji lub pliku wykonywalnego
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>
|
arguments - argumenty zadnia
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>
|
stdin - standardowe wejście
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:
stdout - standardowe wyjście
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:
stderr - standardowe wyjście błędów
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:
stageInOut - deklaracja danych wejściowych/wyjściowych
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:
environment - zmienne środowiskowe
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>
|
reservation - rezerwacje
Element reservation pozwala zdefiniować rezerwację, do której ma być zlecone zadanie.
Element posiada atrybuty:
- type - typ rezerwacji
- QCG - identyfikator rezerwacji założonej przez QCG-Broker,
- LOCAL - identyfikator rezerwacji założonej bezpośrednio w systemie kolejkowym.
- processGroupId - identyfikator grupy procesów, dla której rezerwacja została założona. Istotne w przypadku, gdy rezerwacja założona została dla zadania z grupami procesów.
executionTime - wymagania czasowe
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>
|
workflow - definicja zależności kolejnościowych zadań
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:
parameterSweep - definicja zmienności parametrów
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:
- name - nazwa parametru,
- value - element definiujące zmienność parametru. Zawiera jeden z elementów:
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> |
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 |
Przykładowe opisy eksperymentów
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> |
Wersje klienta tekstowego
SimpleClient
QCG-SimpleClient oferuje prosty, wzorowany na poleceniech systemu kolejkowego, interfejs do infrastruktury QCG.
Polecenia
qcg-sub - zlecenie zadania do wykonania na infrastrukturze QCG zgodnie z uproszczonym opisem,
qcg-list - wyświetlenie listy zleconych zadań wraz z informacjami o nich,
qcg-info - wyświetlenie szczegółowej informacji o danym zadaniu,
qcg-peek - podgląd wyjścia (stdout, stderr) aplikacji,
qcg-proxy - utworzenie certyfikatu proxy użytkownika,
qcg-cancel - anulowanie zadania.
- qcg-clean - usunięcie katalogu roboczego zadnia.
- qcg-interactive - zlecenie zadania interaktywnego
- qcg-refetch - ponowne skopiowanie plików wynikowych zadania.
Składnia poleceń
- qcg-sub
plik_z_opisem
Zlecenie zadania do wykonania na infrastrukturze QCG zgodnie z uproszczonym opisem
plik_z_opisem - ścieżka do pliku z uproszczonym opisem zadania
Code Block |
---|
qcg-sub /home/piontek/tasks/date.qcg
qcg-sub ./tasks/date.qcg
|
- qcg-list
czas_jednostka [stan,[stan]]
Wyświetlenie listy zleconych zadań wraz z informacjami o nich.
czas_jednostka - Opcjonalnie można podać z jakiego czasu mają być zadania - z ostatnich „liczba” dni („d”), godzin („h”), minut („m”).
stan - 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:
- all - zadania we wszystkich stanach,
- terminated - zadania zakończone,
- unterminated - zadania niezakończone.
Code Block |
---|
qcg-list 7d all
qcg-list 7d terminated
qcg-list 7d unterminated
|
- qcg-info
jobId pokaz_opis
Wyświetlenie szczegółowej informacji o danym zadaniu.
jobId - identyfikator eksperymentu.
pokaz_opis - 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
|
- gcg-peek
jobId liczba_znaków
Podgląd wyjścia (stdout, stderr) aplikacji.
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
|
- qcg-proxy
Utworzenie certyfikatu proxy użytkownika.
- qcg-cancel
jobId
Anulowanie zadania.
jobId - identyfikator eksperymentu
Code Block |
---|
qcg-cancel J1331196390748_date_3099
|
- qcg-clean
jobId
Usunięcie katalogu roboczego zadnia.
jobId - identyfikator eksperymentu
Code Block |
---|
qcg-clean J1331196390748_date_3099
|
- qcg-interactive plik_z_opisem
Zlecenie zadania interaktywnego.
plik_z_opisem - ścieżka do pliku z uproszczonym opisem zadania
Code Block |
---|
qcg-interactive /home/piontek/tasks/bash.qcg
qcg-interactive ./tasks/bash.qcg
|
zasoby obliczeniowe dostępne przez QosCosGrid.
Korzystanie z infrastruktury
Aby móc skorzystać z infrastruktury QosCosGrid należy:
Narzędzia dostępowe (zlecanie zadań)
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.
Rozszerzenia QosCosGrid
QosCosGrid oferuje dodatkowo zestaw narzędzi i usług rozszerzających podstawową funkcjonalność narzędzi dostępowych, umożliwiających między innymi rezerwację zasobów obliczeniowych czy śledzenie postępu wykonania długotrwających aplikacji.
Image Added | Image Added |
Kontakt
Image Added | Narzędzia i usługi QosCosGrid rozwijane są przez zespół programistów z Poznańskiego Centrum Superkomputerowo Sieciowego. |
---|
Kontakt: qcg@plgrid.pl
Korzystając z polecenia qcg-interactive można zlecić wykonanie dowolnej interaktywnej tekstowej aplikacji.
Szczegołnie częstym i użytecznym przypadkiem jest interaktywne uruchomienie konsoli poleceń umożliwiające np. kompilację oprogramowani na klastrze, do którego nie ma dostępu poprzez SSH.
W opisie zadania dla interaktywnego uruchomienia konsoli poleceń wystarczy podać nazwę klastra, na którym ma sie uruchomić konsola oraz podać scieżkę do preferowanego interpretera poleceń (np. bash).
Code Block |
---|
#QCG host=inula.man.poznan.pl
/bin/bash |
W opisie zadania interaktywnego można korzystać również z innych dyrektyw QCG celem podania np. wymagań zasobowych dla zadania interaktywnego.
- qcg-refetch
jobId
Ponowne skopiowanie plików wynikowych zadania.
jobId - identyfikator eksperymentu
Code Block |
---|
qcg-refetch J1331196390748_date_3099
|
Przykłady użycia
- qcg-sub - zlecenie zadania
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
|
- qcg-list - lista zadań w systemie
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
|
- qcg-info - pobranie informacji o danym zadaniu
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
|
- qcg-peek - pogranie standardowych strumieni wyjścia zadania
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
|
- qcg-proxy - utworzenie certyfikatu proxy użytkownika
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
|
- qcg-cancel - anulowanie zadania
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
|
AdvancedClient
Klient QCG może być uruchomiony w dwóch trybach:
tryb poleceń – Każde odwołanie do infrastruktury QCG jest pojedynczym wywołaniem klienta, a argumenty tego wywołania są przekazywane bezpośrednio z linii poleceń. Tryb poleceń wykorzystywany jest głównie przy wywoływaniu klienta z wszelkiego rodzaju skryptów, szczególnie wtedy, gdy przetwarzanie odpowiedzi systemu służy sterowaniu przebiegiem eksperymentu,
tryb konsoli – tryb ten działa podobnie jak konsola poleceń systemu operacyjnego Linux/Unix. Wprowadzane przez użytkownika linie tekstu są interpretowane przez klienta. Tryb konsoli daje dodatkową funkcjonalność niedostępną w trybie poleceń taką jak: aliasy, historia poleceń dostępna poprzez klawisze strzałek, uzupełnianie poleceń i ścieżek plików.
Schemat użycia klient zależy od wybranego trybu:
dla trybu poleceń: qcg-client POLECENIE \[ARG1 .. ARGn\]
dla trybu konsoli: qcg-client -console - po czym użytkownik podaje linie tekstu w formacie POLECENIE \[ARG1 .. ARGn\] do przetworzenia i wykonania na infrastrukturze QCG.
Info |
---|
Do uwierzytelnienia i delegacji uprawnień użytkownika klient wymaga poprawnej konfiguracji i dostępu do certyfikatu proxy użytkownika. |
Polecenia
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. |
Dodatkowe polecenia dostępne tylko w trybie konsoli:
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. |
Lista statusów
Statusy eksperymentów
UNCOMMITTED - eksperyment został zlecony z flagą commitWait
i oczekuje na zatwierdzenie,
SUBMITTED – eksperyment został zlecony i jest przetwarzany,
SUSPENDED – przetwarzanie eksperymentu zostało wstrzymane,
ACTIVE – eksperyment jest „aktywny”, przynajmniej jedno zadanie jest przetwarzane,
FINISHED – eksperyment jest zakończony,
FAILED – eksperyment się nie powiódł. Przynajmniej jedno „kluczowe” zadanie zakończyło się błędem.
CANCELED – eksperyment został anulowany,
BROKEN - jedno lub więcej „kluczowych” zadań zakończyło się błędem. System czeka na zakończenie uruchomionych zadań, po czym status eksperymentu zostanie zmieniony na FAILED.|
Statusy zadań
UNSUBMITTED – przetwarzanie zadania wstrzymane z powodu zależności kolejnościowych,
UNCOMMITED - zadanie oczekuje na zatwierdzenie do przetwarzania,
QUEUED – zadanie oczekuje w kolejce na przetwarzanie,
PREPROCESSING – system przygotowuje środowisko uruchomieniowe dla zadania,
PENDING – aplikacja w ramach danego zadania oczekuje na wykonanie w systemie kolejkowym,
RUNNING – aplikacja użytkownika jest wykonywana w ramach zadania,
STOPPED – aplikacja została zakończona, system nie rozpoczął jeszcze czynności związanych z kopiowaniem wyników i czyszczeniem środowiska wykonawczego,
POSTPROCESSING – system wykonuje akcje mające na calu zakończenie zadania: kopiuje pliki/katalogi wynikowe, czyści środowisko wykonawcze, etc.,
FINISHED – zadanie zostało zakończone,
SUSPENDED – przetwarzanie zadania zostało wstrzymane,
FAILED – błąd przetwarzania zadania,
CANCELED – zadanie anulowane przez użytkownika.
Przykłady użycia
Uruchomienie klienta w trybie konsoli
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> |
Zlecenie zadania
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
|
Pobranie listy eksperymentów
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
|
Monitorowanie eksperymentu
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
|
Monitorowanie zadań
Code Block |
---|
------ TasksMonitor --------
JobID: J1323294704605_reef_test_3932
Number of tasks: 1
date : FINISHED ( qcg.reef.man.poznan.pl )
Press ESC to break
|
Monitorowanie zadania
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>
|
Anulowanie eksperymentu
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
|
Wyświetlenie pliku z opisem eksperymentu
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>
|
Rezerwacja zasobów
Code Block |
---|
qcg> create_reservation ./tests/rezerwacje/reservation.xml
reservationId = R1323347194781_RESERVATION_7460
|
Pobranie listy rezerwacji
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
|
Anulowanie rezerwacji
Code Block |
---|
qcg> cancel_reservation $$
Command translated to:
cancel_reservation R1323347194781_RESERVATION_7460
|
Graficzne narzędzia dostępowe
QCG-Icon
QCG-Icon jest lekką aplikacją dostępną na platformy Windows, MAC OSX oraz Linux mająca na celu udostępnianie wybranych aplikacji zainstalowanych na zasobach obliczeniowych projektu PL-Grid poprzez usługi QosCosGrid. Przy tworzeniu aplikacji położono szczególny nacisk na to by korzystanie aplikacji zainstalowanej „w Gridzie” było tak intuicyjne jak korzystanie z aplikacji zainstalowanych lokalnie. W obecnej wersji aplikacji możliwe jest uruchamianie sumulacji Gaussian, NAMD oraz skryptów napisanych w języku MATLAB, R i BASH. Lista wspieranych aplikacji nieustannie rośnie.
Więcej informacji na stronie domowej projektu lub w podręczniku użytkownika.
Image Removed
Nanotechnology-Gateway
Środowisko portalowe dla naukowców z dziedziny nanotechnologii – Nanotechnology Gateway. Aktualna wersja zintegrowana jest z aplikacjami ABINIT, Quantum Espresso oraz NAMD i NW-Chem a jej podstawową funkcjonalnością jest przygotowywanie danych wejściowych, zlecanie zadań do rozproszonych systemów komputerowych, monitorowanie stanu i kontrolowanie symulacji, przetwarzanie i analiza rezultatów, przechowywanie i archiwizacja danych. Oprócz tego dostępne są w pełni zautomatyzowane operacje na danych, jak ich przenoszenie, konwersja, przetwarzanie oraz wizualizacja. Najbardziej zaawansowaną częścią portalu jest klient aplikacji ABINIT. Pakiet oprogramowania do symulacji ABINIT pozwala między innymi na rozwiązywanie następujących problemów: wyznaczanie energii całkowitej, gęstości ładunkowych oraz struktury elektronowej układów kwantowo-mechanicznych (elektrony, jądra atomowe) w oparciu o założenia teorii funkcjonału gęstości (pseudopotencjały oraz bazę fal płaskich).
Image Removed
Kontakt
Kontakt: contact@qoscosgrid.org
Zgłaszanie problemów: http://helpdesk.plgrid.pl
Lista dyskusyjna: support@lists.qoscosgrid.org