Infrastruktura QosCosGrid

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 tym czasu wykonania zadania poprzez wykorzystanie zaawansowanych mechanizmów rezerwacji zasobów z wyprzedzeniem.
• 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.
• 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:

• 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.

.

Szczegółowe informacje o dostępnych zasobach znajdują się na stronie:zasoby obliczeniowe dostępne przez QosCosGrid.

Korzystanie z infrastruktury

Aby móc skorzystać z infrastruktury QosCosGrid należy:

• aplikować o dostęp do infrastruktury QosCosGrid
• skorzystać z wybranej metody dostępowej

...

• ogólny klient tekstowy
• graficzne narzędzia dostępowe dla wybranych aplikacji

Aplikowanie o usługę

Kolejność kroków

1. Rejestracja w Portalu PL-Grid.
2. Wystąpienie o certyfikat użytkownika PL-Grid.
3. Rejestracja certyfikatu w Portalu PL-Grid.
4. Aplikowanie o dostęp do infrastruktury QosCosGrid.
5. 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

2. Wystąpienie o certyfikat

3. Rejestracja certyfikatu w PL-Gridzie

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

Maszyna dostępowa QCG

...

ssh plgpiontek@qcg.man.poznan.pl

module load qcg

Image Removed

Formaty opisu zadań

Zmienne opisu zadania

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”.

Lista dyrektyw

• queue - wybór kolejki
• note - opis zadania
• name - nazwa zadania
• output - standardowe wyjście
• error - standardowe wyjście błędów
• input - standardowe wejście
• host - wybór klastra
• stage-in-file - plik wejściowy
• stage-in-dir - katalog wejściowy
• stage-out-file - plik wynikowy
• stage-out-dir - katalog wynikowy
• grant - grant
• argument - argument aplikacji
• environment - zmienna środowiskowa
• executable - plik wykonywalny
• application - aplikacja
• persistent - usuwanie katalogu roboczego
• procs - liczba procesów
• nodes - topologia aplikacji
• walltime - czas wykonania
• memory - pamięć
• properties - parametry węzłów
• preprocess - prolog zadania
• postprocess - epilog zadania
• monitor - skrypt monitorujący zadanie

queue

• queue - wybrana kolejka systemu kolejkowego.

  Code Block
  #QCG queue=plgrid

note

• note - krótka informacja o zadaniu.

  Code Block
  #QCG note=moje pierwsze zadanie QCG

name

• name - dyrektywa określająca nazwę zadania. Nazwa zadania pojawi się jako końcówka identyfikatora zadania.

  Code Block
  #QCG name=nobel-experiment

output

• 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

• 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

• 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

• 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

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ą.

#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-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

• 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

• 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

• grant - nazwa grantu, w ramach którego ma być wykonane zadanie.

  Code Block
  #QCG grant=plgpiontek_grant

argument

• 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

• 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

• 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

• application - nazwa aplikacji do uruchomienia.

  Code Block
  #QCG application=namd

persistent

• 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

• procs - liczba rdzeni obliczeniowych, na których ma być wykonane zadanie. (Stosowane dla zadań MPI.)

  Code Block
  #QCG procs=32

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

• memory - dyrektywa definiująca deklarowane maksymalne zapotrzebowanie aplikacji na pamięć operacyjną. Podana wartość jest w MB.

  Code Block
  #QCG memory=1024

properties

• 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

• 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

• 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

• 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

Przykładowe opisy

• 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 *

• Eksperyment polegający na:
  
  • przegraniu z katalogu, z którego wykonano polecenie qcg-sub podkatalogu inputs na klaster na docelowy klaster (reef).
  • zleceniu do wykonania na klastrze reef w kolejce plgrid polecenia /bin/tar pakującego przegrany wczesnej katalog inputs do pliku output.tgz.

  • 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

WOROKING

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.

<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),

<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.

<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.

<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

<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>

...

• (klienta).

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.

Image Added	Image Added	Image Added

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
Zgłaszanie problemów: http://helpdesk.plgrid.pl