Algorytm Fairshare

Niniejszy artykuł objaśnia zasady ewidencjonowania zasobów i priorytetyzowania zadań w slurmie. Wiedza o tym jak slurm oblicza priorytet zadań nie jest niezbędna do używania klastra, ale brak może doprowadzić do nieefektywnego wykorzystania klastra i w konsekwencji obniżenia priorytetu kolejnych zadań.

Ze względu na to, że zasoby są ograniczone, a potrzeby użytkowników liczne, SLURM musi nieustannie podejmować decyzję w jakiej kolejności uruchamiać zadania. Slurm będzie jednocześnie starał się zapewnić maksymalne wykorzystanie klastra i sprawiedliwy przydział zasobów. W tym celu SLURM prowadzi ewidencję wykorzystania zasobów i na podstawie dotychczasowego wykorzystania klastra przydziela odpowiednie priorytety przyszłym zadaniom.

Nie. Niektóre grupy użytkowników mogą być uprzywilejowani względem innych. Wynika to ze sposobu finansowania komponentów klastra. Podzespoły klastra mogą być finansowane z konkretnych grantów i dedykowane dla konkretnych grup badawczych. Byłoby jednak marnotrawstwem rezerwowanie zasobów na wyłączność. Dlatego w sytuacji gdy grupa “sponsorująca” nie wykorzystuje w danej chwili zasobów, nadal mogą być one wykorzystywane przez pozostałych użytkowników. W takiej sytuacji grupa może otrzymać większy przydział zasobów w postaci tzw. udziału.

Udziały należy rozumieć podobnie do analogicznego pojęcia ze świata biznesu. Jest nie jako “przynależna” część klastra, czyli odsetek zasobów jakie może wykorzystać dana grupa użytkowników. W świecie SLURM'a udziały są definiowane podczas tworzenia kont (chodzi o rodzaj kont bankowych, na których zapisywane jest ilość zużytych zasobów - nie należy ich mylić z kontami użytkowników, używanymi do logowania). Konta mają strukturę hierarchiczną. Na szczycie hierarchii znajduje się wydział, który następnie dzieli swoje udziały na grupy badawcze oraz projekty indywidualne. Każdy projekt ma swój własne konto.

Do każdego konta jest przypisany jego udział, oraz jest na nim zapisana ilość zużytych zasobów. Użytkownicy są przypisani do kont. Większość użytkowników jest przypisana tylko do jednego konta, które jest dla nich kontem domyślnym. Niektóre osoby (działające w kilku projektach) mogą być przypisane do różnych kont. W takiej sytuacji użytkownik powinien pamiętać aby podczas uruchamiania zadania explicite wskazywać na które konto ma zostać zapisane zużycie. W przeciwnym razie będzie zawsze obciążać swoje konto domyślne (zazwyczaj pierwsze w kolejności jakie pojawiło się w systemie). Może to zrobić dodając flagę -A <nazwa_konta> lub --account=<nazwa_konta>.

Nazwa konta to najczęściej numer grantu obliczeniowego nadanego podczas zakładania konta. Można również sprawdzić do jakich kont jest się przypisanym przy pomocy polecenia: sshare

Jeśli użytkownik nie jest przypisany do żadnego konta, to SLURM nie pozwoli na uruchomienie zadania. Jeśli uważasz, że brak przypisania stanowi błąd lub pomyłkę, to należy się skontaktować z nami mailowo: hpc@mini.pw.edu.pl

<To be done>

Każdy użytkownik jest przypisany do konta i na którym jest zapisane jakieś zużycie. Obie te wartości są normalizowane do wartości [0-1]. W listingu polecenia sprio są widoczne w kolumnach NormShares oraz EffectiveUsage. Następnie obliczany jest tzw. FairshareFactor (FS) na podstawie formuły:

FS = -2 ^ (-EffectiveUsage / NormShares)

Z tej funkcji płynie kilka wniosków:

• Wartość FS zawiera się w przedziale [1-0),
• Wartość FS spada wykładniczo do zera wraz z rosnącym zużyciem,
• Im większy udział tym wolniej spada,
• Wartość FS rośnie gdy rośnie zużycie innych osób (ponieważ EffectiveUsage jest odsetkiem naszego wykorzystania względem innych użytkowników).

Możliwe są następujące interpretacje tego wskaźnika:

• FS = 1 - użytkownicy przypisani do tego konta nie żużyli żadnego z przydzielonych im zasobów.
• 0.5 < FS < 1 - użytkownicy wykorzystują mniej niż im się należy.
• FS = 0.5 - użytkownicy wykorzystują dokładnie tyle im się należy.
• 0 < FS < 0.5 - użytkownicy wykorzystują więcej niż im się należy.

Po wysłaniu zadania do kolejki (o ile nie zostaje ono uruchomione natychmiast) SLURM oblicza priorytet zadania. Priorytet jest liczbą całkowitą, która jest ważoną sumą dwóch czynników:

• Fairshare Factor (FS)
• Wiek zadania - task age (TA)

A więc Priorytet = FS * w_FS + TA * w_TA

Wiek zadania rośnie liniowo od 0 do jedynki w taki sposób, że maksymalna wartość jest osiągana po 7 dniach oczekiwania w kolejce. A więc im dłużej zadanie tkwi w kolejce tym większy otrzymuje priorytet. Wagi mają następujące wartości:

• w_FS = 200000
• w_TA = 100000

Liczby są tak duże, aby mieć dość “rozdzielczości” by zminimalizować powstawanie “remisów”. Ponadto czynnik związany z Fiarshare jest dwa razy bardziej istotny wiek zadania. Dzięki temu zadanie grupy, która wykorzystała wszystkie swoje zasoby i które czeka tydzień i więcej otrzymuje taki sam priorytet co nowe zadanie grupy, która używa tyle zasobów ile ma przewidziane.

Aby zbadań priorytet swoich zadań oraz poszczególne składowe należy użyć polecenia sprio.

FS rośnie na dwa sposoby:

1. Po pierwsze FS rośnie, gdy spada nasz EffectiveUsage - czyli odsetek naszego wykorzystania klastra. Im więcej innych osób będzie używać klaster, tym większy będzie nasz FS.
2. Po drugie FS będzie w czasie wracać do wartości 1.0000. Jego “czas półtrwania” wynosi 2-tygodnie, oznacza, że nasza praca sprzed dwóch tygodni będzie miała tylko połowę wpływu na FS co nasza praca z ostatnich dni, a praca sprzed 4-rech tygodni zaledwie 1/4 wpływu.

Gdy na klastrze jest dość zasobów by uruchomić zadanie, to zostanie uruchomione bez względu na wysokość FS. Nadal jednak zostanie odnotowane ilość zużytych zasobów i wypłynie to na na wartość FS obliczaną dla kolejnych zadań. Jest to nie jako pożyczenie “czasu” z przyszłości. Stosując analogię ze świata finansów jest to rodzaj zaciągnięcia długu.

Jeśli na klastrze jest tłok, a Twoje zadania notorycznie otrzymują niski priorytet, to należy zbadać przy pomocy sprio co powoduje tak niski priorytet. Jeśli przyczyną jest niski FS, to poniżej znajduje się lista rzeczy, które możesz zrobić:

1. Czekaj - Im więcej osób wykona obliczenia przed Tobą tym wyższy będzie Twój FS. Jeśli Twój projekt wymaga precyzyjnego przestrzegania deadline'ów i wiesz, że w określonym terminie będzie Ci potrzebny dostęp do klastra i podejrzewasz, że może to być okres wzmożonego ruchu, to najlepiej jest zaplanować obliczenia z kilkutygodniowym wyprzedzeniem i powstrzymać osoby ze swojego projektu przed uruchamianiem zadań. Wówczas FS - “naładuje się” i umożliwi używanie klastra w gorącym okresie.
2. Bądź cierpliwy - Ta porada jest tylko pozornie powiązana z powyższą. Odnosi się do drugiego czynnika obliczania priorytetu zadania - jego wieku. Zadanie otrzymuje dodatkowy priorytet im dłużej tkwi w kolejce. Maksymalny priorytet otrzyma po 7-miu dniach.
3. Bądź miły dla SLURMA - praca SLURMA przypomina układanie wielowymairowego tetrisa, w którym wymiarami klocków są zapotrzebowanie na Czas, CPU, GPU i RAM. SLURM'owi będzie łatwiej ułożyć tego tetrisa, jeśli klocki będą małe. SLURM alokuje zadania w dwóch cyklach pracy:
   • W pierwszym cyklu SLURM alokuje zadania w kolejności wyznaczonej przez kolejkę priorytetową, aż do wysycenia zasobów.
   • W drugim cyku SLURM przeszukuje listę zadań szukając dostatecznie małych zadań, które zmieściłyby w “dziurach” pomiędzy dużymi zadaniami. Wiele osób “przestrzeliwuje” swoje realne potrzeby rezerwując zbyt wiele zasobów do swoich potrzeb. Zwłaszcza w kwestii RAM. Warto monitorować swoje zadania, pod tym kątem, ponieważ po pierwsze obniżają one FS konta, a po drugie dłużej oczekują w kolejce. Doskonałym narzędziem do monitorowania efektywności zadań jest narzędzie seff
4. Rozbuduj klaster - jeśli dana grupa badawcza ma permanentnie potrzeby przewyższające obecne możliwości klastra, może to być sygnał, że warto rozważyć zakup dodatkowego sprzętu. W takiej sytuacji zakup dodatkowych serwerów obliczeniowych, które będą mogły być włączone do klastra skutkować będzie zwiększeniem wskaźnika NormShare i tym samym kolejne zadania będą otrzymywać wyższy priorytet.

W chwili pisania tego artykułu:

1. obecnie wyłącznie wykorzystanie CPU jest naliczane w billingu, ale trwają prace konfiguracyjne i testowe, które w przyszłości pozwolą w billingu uwzględniać składowe GPU i RAM. Procesory różnej wydajności będą miały odmienne wagi.
2. aktualne proporcje udziałów drukowane przez polecenie share funkcjonują testowo i mogą się zmieniać w czasie w procesie dostrajania klastra do potrzeb użytkowników