Użycie systemu SLURM¶

Węzeł logowania¶

Gdy użytkownik łączy się z klastrem, jest on połączony z jednym komputerem współdzielonym ze wszystkimi innymi użytkownikami, zwanym „węzłem logowania”. Celem węzła jest przesyłanie zadań, kopiowanie danych, edytowanie skryptów itp. Nie wolno uruchamiać żadnych obliczeń bezpośrednio na tym węźle.

Węzły obliczeniowe¶

Komputery te wykonują ciężką pracę związaną z prowadzeniem obliczeń. Jednak użytkownik nie wchodzi z nimi w bezpośrednią interakcję. Zamiast tego, poleca on systemowi kolejkowania SLURM uruchomienie żądanych aplikacji, zaś SLURM znajduje dostępne węzły obliczeniowe i uruchamia na nich obliczenia.

Zasoby obliczeniowe¶

Klaster HPC składa się z pewnej liczby węzłów obliczeniowych, z których każdy posiada zestaw procesorów, pamięci i (ewentualnie w przyszłości) układów GPU. Użytkownik przesyła zadania które określają jakie programy mają zostać uruchomione na tych węzłach, wraz z opisem wymaganych zasobów obliczeniowych.

Użytkownik może przesyłać zarówno zadania szeregowe, jak i równoległe. Zadanie szeregowe jest wykonywane na pojedynczym węźle przy użyciu dokładnie jednego procesora CPU. Zadania równoległe mogą współdzielić pamięć na pojedynczym węźle lub działać jako oddzielne procesy komunikujące się ze sobą. W celu wybrania typu uruchamianego zadania, należy określić ilość procesów (task) i liczbę procesorów dla każdego zadania. Poniższa tabela podsumowuje możliwe typy zadań.

Należy pamiętać, że liczba zadań pomnożona przez liczbę procesorów na zadanie może nie może przekraczać 108, chyba że zadania uruchamiane są w kolejce free.

W przypadku klastra dragon każdy użytkownik ma możliwość wykorzystania do 3240G pamięci RAM, a zasoby zależą od używanej kolejki, jak to określono w poniższej tabeli:

Zadania wsadowe¶

Aby przesłać skrypt wsadowy do SLURM, należy użyć polecenia sbatch. Jest ono zaprojektowane w taki sposób, aby umożliwić użytkownikowi przesłanie zadań wsadowych do systemu kolejkowania, jeśli żądają one zasobów, które nie mogą być dostarczone zgodnie ze specyfikacją. Daje to możliwość weryfikacji zadania i ponownego przesłania go z niezbędnymi poprawkami.

Zadania interaktywne¶

Zadanie interaktywne to zadanie, które udostępnia użytkownikowi wiersz poleceń (zamiast uruchomienie skryptu), gdy zostanie uruchomione. Aby przesłać interaktywne zadanie do do SLURM należy użyć polecenia salloc. Gdy żądane zasoby zostaną przydzielone, pojawi się wiersz poleceń i będzie można uruchomić program(y) za pomocą polecenia srun.

W poniższy przykładzie żądany jest węzeł obliczeniowy dla jednego zadania i alokowane jest 2GB pamięci RAM oraz 4 procesory dla zadania interaktywnego, które może trwać do jednej godziny. Następnie pokazane jest przykładowe uruchomienie polecenia your_application na przydzielonym węźle:

user@dragon:~$ salloc --time=1:00:00 --mem=2G -n1 -c4
salloc: Przyznano przydział zadania 1234
[1234] user@dragon:~$ srun your_application

Anatomia zadania wsadowego¶

Zadania wsadowe wykonywane są na węzłach obliczeniowych bez udziału użytkownika. W zadaniach tych definiuje się wymagane zasoby obliczeniowe, programy do uruchomienia oraz wszelkie dane wejściowe i opcje wyjściowe. Użytkownik przesyła zadanie, zwykle w formie skryptu zadania wsadowego, do nadzorcy zadań. Jest to preferowany sposób korzystania z klastra.

Skrypt zadania wsadowego składa się z czterech głównych elementów:

• Określenia interpretera używanego do wykonywania skryptu,

• dyrektyw #SBATCH, które definiują domyślne parametry zadania.

• definicji zmiennych środowiskowych i modułów (jeśli to konieczne).

• komend uruchamiających właściwe obliczenia z ich argumentami wejściowymi i opcjami.

Oto przykład skryptu wsadowego, w którym zdefiniowano uruchomienie 8 zadań na dwóch węzłach, przydzielając łącznie 2GB pamięci RAM na każdy węzeł. Obliczenia mogą trwać maksymalnie jedną godzinę. Jest on przypisany do kolejki normal. Kiedy zadanie jest uruchamiane, ładowany jest moduł my_module i uruchamiany program my_application na przydzielonych węzłach:

#!/bin/bash
#SBATCH -n 8 -N 2
#SBATCH --time=1:00:00
#SBATCH --mem=2G
#SBATCH --qos=normal
module add my_module
srun my_application

Gdy zadanie zostanie zaplanowane do uruchomienia, menedżer zasobów wykona skrypt zadania wsadowego na pierwszym przydzielonym węźle. Polecenie srun uruchomi dodatkowe zadania na wszystkich przydzielonych węzłach.

Konkretne instrukcje dotyczące uruchamiania dostępnych programów są przedstawione w osobnym rozdziale.

Określenie wymaganych zasobów¶

Uruchamiając zadania na klastrze należy ręcznie określić wymagane zasoby. Jeśli użytkownik zapomni tego zrobić, zadanie otrzyma 1KB pamięci RAM i będzie mogło działać tylko przez 1 minutę. Zasoby określa się jako argumenty wiersza poleceń programu do sbatch lub salloc lub w dyrektywie #SBATCH skryptu.

Podstawowe zasoby są następujące:

Podczas przesyłania zadań należy dokładnie rozważyć wymagane zasoby. Określenie zbyt niskich wartości naraża zadanie na ryzyko przerwania, zaś ustawienie zbyt wysokich wartości marnuje zasoby klastra i zmniejsza priorytet zadania. Co więcej, małe zadania mogą być uruchamiane wcześniej w celu wypełnienia wolnych obszarów zasobach klastra, przy użyciu tzw. algorytmu backfill.

$ seff JOBID

$ seff 1592
Job ID: 1592
Cluster: dragon
User/Group: user/user
State: COMPLETED (exit code 0)
Cores: 48
Nodes: 4 (12 cores per node)
Tasks: 24 (2 cores per task)
Elapsed Time: 00:08:02
CPU Utilized: 04:36:28
CPU Efficiency: 71.70% of 06:25:36 core-walltime
Max Memory Utilized: 2.74 GB (up to 934.75 MB/node)
Memory Efficiency: 68.46% of 4.00 GB (1.00 GB/node)

Nazwy zadań i pliki wyjściowe¶

Wszystkie zadania otrzymują zarówno identyfikator zadania, jak i nazwę, w celu ich łatwiejszej identyfikacji w systemie wsadowym. Domyślną nazwą nadawaną zadaniu jest nazwa pliku skryptu zadania, co może utrudnić identyfikację zadania, w przypadku używania standardowej nazwy dla wielu skryptów. Dowolnemu zadaniu można nadać własną nazwę za pomocą opcji -J:

#SBATCH -J test_parametrow

Spowoduje to nazwanie zadania „test_parametrow”.

Domyślnie - dla zadań przesłanych z sbatch - dane wyjściowe, które zadanie zapisuje do stdout i stderr są zapisywane do pliku o nazwie slurm_%j.out. Znak %j w nazwie pliku zostanie zastąpiony numerem zadania przypisanym przez SLURM. Zapewnia to, że plik wyjściowy zadania jest unikalny i nie będzie kolidował z plikami wyjściowymi innych zadań.

W wielu przypadkach domyślna nazwa pliku nie jest wygodna. Być może potrzebna jest nazwa pliku, która jest bardziej opisowa dla faktycznie uruchomionego zadania, lub zawierająca ważne metadane, takie jak parametry fizyczne. Nazwę plików wyjściowych można zmienić za pomocą opcji -o i -e programu sbatch. Opcja -o określa nazwę pliku zawierającego stdout, zaś opcja -e pliku zawierającego stderr. Dobrą praktyką jest dołączenie łańcucha %j do nazw plików. Zapobiegnie to nadpisywaniu plików plików wyjściowych. Poniżej znajduje się przykład:

#SBATCH -o calcflow-%j.out
#SBATCH -e calcflow-%j.err

Możesz podać tę samą nazwę pliku dla obu opcji, aby zapisać stdout i stderr do tego samego pliku. Również jeśli po prostu pominięta zostanie opcja -e, to stderr zostanie zapisany do tego samego pliku co stdout.

W przypadku używania tablic zadań, można zastąpić identyfikator zadania %j znakiem %a, który daje identyfikator całej tablicy i %A dla numeru elementu tablicy:

#SBATCH -o myarray-%a_%A.out

Partycje¶

Zadania SLURM są wykonywane na węzłach obliczeniowych. Ilość i rodzaje zasobów (procesory, pamięć, pamięć dyskowa itp.) mogą być zróżnicowane dla różnych węzłów obliczeniowych. Aby uzyskać przegląd węzłów i sprawdzić ich stan, należy zalogować się do klastra i wykonać polecenie:

$ sinfo

Partycje są używane przez SLURM do grupowania węzłów o identycznej lub podobnej konfiguracji. W przypadku klastra dragon — gdzie węzły są identyczne — nie ma potrzeby zwracać szczególnej uwagi na partycje. Każde zadanie zostanie przypisane do partycji najlepiej dostosowanej do zdefiniowanych wymogów.

Aby ręcznie wybrać partycję, należy użyć opcji -p poleceń sbatch i salloc lub w dyrektywie #SBATCH skryptu uruchomieniowego.

Priorytety zadań¶

Po przesłaniu zadania wsadowego lub zażądaniu zasobów dla zadania interaktywnego, zadanie to niekoniecznie jest uruchamiane natychmiast. Zamiast tego zadania zostaną uporządkowane w kolejce oczekujących zadań w oparciu o szereg czynników. Nadzorca zawsze będzie dążył do uruchomienia zadania znajdującego się na szczycie kolejki. Jeśli jednak zadanie zadanie nie wymaga wielu zasobów, może ono zostać uruchomione wcześniej, o ile nie opóźni rozpoczęcia żadnego zadania o wyższym priorytecie (jest to tzw. back-fill, czyli konserwatywne wypełnianie).

Czynniki wpływające na priorytet zadania można zobaczyć wywołując polecenie sprio. Czynniki te obejmują:

• Fair-share: liczba wskazująca, w jakim stopniu użytkownik korzystał ostatnio z klastra. Jest to najważniejszy czynnik, ponieważ zapewnia, że wszyscy użytkownicy będą mogli rozpocząć swoje zadania w rozsądnym czasie. Bieżące użycie można sprawdzić sprawdzić za pomocą polecenia sshare:

  $ sshare
     Account       User  RawShares  NormShares  EffectvUsage  FairShare
  ---------- ---------- ---------- ----------- ------------- ----------
  root                                1.000000      1.000000   0.500000
   physics                       1    0.500000      1.000000   0.250000
    physics    username          1    0.125000      0.874713   0.007825
  

• Rozmiar zadania: liczba proporcjonalna do ilości zasobów obliczeniowych, których zażądało zadanie zasobów obliczeniowych. Mniejsze i krótsze zadania będą miały wyższy priorytet.

• Wiek: liczba proporcjonalna do czasu, jaki upłynął od przesłania zadania do kolejki.

• QOS: liczba przypisana do wybranej kolejki. Poniżej znajdują się szczegółowe informacje.

Przesyłanie tablic zadań¶

Tablice zadań są przesyłane z pomocą opcji -a lub --array w wywołaniu polecenia sbatch lub przez dołączenie dyrektywy #SBATCH -a do skryptu SLURM. Opcja -a przyjmuje rozdzielaną przecinkami listę numerów ID zadań lub jedną albo więcej par numerów ID zadań rozdzielonych myślnikiem.

Każde zadanie w tablicy zadań zostanie uruchomione z tym samym skryptem SLURM i w identycznym środowisku — z wyjątkiem wartości jego identyfikatora w tablicy. Wartość tego identyfikatora jest zapisywana w zmiennej środowiskowej SLURM_ARRAY_TASK_ID.

Na przykład, jeśli potrzebna jest tablica zadań z 10 elementami, ponumerowanymi od 1 do 10, polecenie przesłania byłoby następujące:

$ sbatch -a 1-10 array_script.sh

Można również określić wyraźne indeksy tablicy oddzielone przecinkami, albo dodać krok do określonego zakresu, używając „:”. W związku z tym poniższe polecenia są równoważne:

$ sbatch --array 0-20:4 array_script.sh
$ sbatch -a 0,4,8,12,16,20 array_script.sh

Ma końcu opcji -a może być dodany opcjonalny parametr, określający maksymalną liczbę elementów tablicy mogących, które mogą być uruchomione jednocześnie. Limit slotów jest określany przez dołączenie „%” do opcji -a po którym następuje wartość limitu. Na przykład, dwunastoelementową tablicę zadań z niesekwencyjnymi identyfikatorami i limitem slotów wynoszącym 3 można określić w następujący sposób:

$ sbatch -a 1-3,5-7,9-11,13-15%3 array_script.sh

Każde zadanie zawarte w tablicy zadań ma własną unikalną wartość indeksu w tablicy przechowywaną w zmiennej środowiskowej SLURM_ARRAY_TASK_ID. Wartość taj est dostępna w skrypcie zadania, tak jak każda inna zmienna środowiskowa. Jeśli zadanie uruchomiło skrypt powłoki bash, informacje o identyfikatorze tablicy zadania można wydrukować za pomocą następującego polecenia:

echo "Identyfikator tablicy elementu bieżącego zadania: ${SLURM_ARRAY_TASK_ID}"

Dostosowywanie danych dla tablicy zadań¶

Bardziej użytecznym wykorzystaniem indeksu w tablicy, pokazującym prawdziwą moc tablic, byłoby użycie go jako bezpośredniego lub pośredniego indeksu do danych przetwarzanych przez tablicę zadań.

Jedną z możliwości osiągnięcia tego celu jest użycie wartości SLURM_ARRAY_TASK_ID w celu zapewnienia niestandardowego zestawu parametrów wejściowych. Aby aby to zrobić, należy utworzyć plik tekstowy zawierający wiele wierszy, z których każdy składa się z szeregu wartości oddzielonych spacjami. W tym podejściu każdy wiersz w pliku danych zawiera parametry wejściowe wymagane przez jedno zadanie z tablicy. Skrypt SLURM należy zmodyfikować tak, aby zawierał on polecenie wczytujące właściwy wiersz pliku danych na podstawie parametru SLURM_ARRAY_TASK_ID. Istnieje wiele sposobów na odczytanie odpowiedniego wiersza z pliku danych. Poniżej pokazana jest przykładowa implementacja przy założeniu, że plik danych został nazwany data.dat i znajduje się on w tym samym katalogu, co skrypt uruchamiany dla każdego elementu tablicy zadań:

PARAMETERS=$(sed "${SLURM_ARRAY_TASK_ID}q;d" data.dat)

Zakładając, że program wykonywalny dla zadań w tej tablicy ma nazwę command.sh, skrypt SLURM powinien wyglądać jak poniżej:

./command.sh ${PARAMETERS}

Alternatywne podejście jest możliwe, jeśli unikalne parametry wejściowe wymagane przez każde zadanie w tablicy można obliczyć arytmetycznie. Na przykład, jeśli każda instancja skryptu command.sh wykonuje pętlę na jakimś zakresem wartości, w skrypcie SLURM można obliczyć maksymalne i minimalne wartości potrzebne dla każdego zadania bezpośrednio na podstawie wartości w zmiennej środowiskowej SLURM_ARRAY_TASK_ID. Jeśli zakres w każdym zadaniu obejmuje 1000 wartości, można by to zrobić, włączając do skryptu SLURM następujące polecenia:

MAX=$(echo "${SLURM_ARRAY_TASK_ID}*1000" | bc)
MIN=$(echo "(${SLURM_ARRAY_TASK_ID}-1)*1000" | bc)

W tym podejściu plik danych, o którym mowa powyżej (data.dat) nie jest potrzebny, a wywołanie skryptu SLURM uruchamiające polecenie command.sh może wyglądać następująco:

command.sh ${MIN} ${MAX}

Najważniejsze zmienne środowiskowe¶

Specyfikacja zadań¶