r22 - 20 Nov 2008 - 09:51:29 - JanaUhlirovaYou are here: TWiki  >  VS Web > VsDokumentace > VsGolias

Dokumentace pro uživatele farmy Goliáš

Pro snažší komunikaci s uživateli byl zaveden RT (Request Tracking) system . Proto veškeré dotazy a problémy spojené s farmou Goliáš zasílejte výhradně na e-mailovou adresu fzu zavináč rt3.cesnet.cz .

Upozornění:

ALERT! Dne 19.11.2008 byl definitivně vypnut server prak2.farm.particle.cz.

Ke stažení

Obsah:

1. Základní informace

1.1 Struktura farmy Goliáš

  • golias.farm.particle.cz

Na tomto stroji běží server systému PBSPro (Portable Batch System), který má na starosti plánování a spouštění úloh na farmě Goliáš.

  • ui2.farm.particle.cz
  • prak3.farm.particle.cz

Na tyto servery se uživatel přihlašuje. (V současné době si sám zvolí, na který stroj se zaloguje). Na těchto serverech je nainstalován klient systému PBS. Uživatel může své úlohy spouštět, rušit, přesouvat ve frontách, vyzvedávat výsledky. Zároveň může provádět další interaktivní činnosti jako např. testovat nebo kompilovat své programy. Výhledově bude pro interaktivní činnosti vyhrazeno několik výpočetních uzlů golias.

  • golias01 - golias162

Toto jsou výpočetní neboli pracovní uzly (tzv. worker nody). Nepatří mezi ně golias 10, 15, 25, 31, 32, 33, 59, 97, 98, 100, 137 a 143. (Pro úplnost golias31 - golias99 jsou aliasy pro goliasx31 - goliasx99). Na těchto strojích systém PBS spouští úlohy. Uživatel by se na ně neměl bezdůvodně hlásit.

  • storage.farm.particle.cz
  • storage2.farm.particle.cz
  • storage3.farm.particle.cz
  • storage4.farm.particle.cz
  • storage5.farm.particle.cz

Toto jsou fileservery, na kterých jsou uložena data a domovské adresáře. Pomocí NFS jsou namountovány na serverech golias, ui2 a prak3 jako adresáře /raidN, kde N je číslo v názvu serveru. Pokud je součástí jména adresáře /raidN i jméno experimentu, znamená to, že tento adresář může být využíván pouze pro daný experiment. Soubory uložené v adresáři /raidN se nezálohují! Uživatel si musí soubory sám zkopírovat na jiné místo. Zálohují se pouze domovské adresáře /home.

Zpět

1.2 Nový uživatel

Každý nový zájemce o používání farmy Goliáš musí vyplnit Žádost o zřízení účtu. Žádost je nutné v papírové formě zaslat na sekretariát Sekce fyziky elementárních částic FZÚ. Pro urychlení celé procedury je možné žádost poslat faxem (fax: 286 585 443) a originál doručit do čtrnácti dnů.

Jakmile obdržíte e-mailem potvrzení o zřízení účtu, je nutné se přihlásit na golias.farm.particle.cz a potom na ui2.farm.particle.cz nebo na prak3.farm.particle.cz a pomocí příkazu passwd změnit přístupové heslo. Heslo by mělo být silné, tzn. mělo by se skládat alespoň z 8 znaků a obsahovat malá a velká písmena, číslice a nealfanumerické znaky (např. %, &, *, # apod.).

Pozn.: Po dokončení instalaci systému LDAP ( Lightweight Directory Access Protocol ) bude nový uživatel při prvním přihlášení na ui2 nebo prak3 automaticky vyzván ke změně svého hesla. Dokud si heslo nezmění, nebude mít možnost dále pracovat.

Každý nový uživatel farmy Goliáš je automaticky přihlášen do e-mailové skupiny hepfarm zavináč heplist.fzu.cz. Prostřednictvím toho e-mailu bude informován o novinkách, o změnách v konfiguraci, o plánovaném výpadku farmy apod.

Zpět

2. Datové prostory

2.1. Domovský adresář /home

Kvóty

Adresář /home je vidět ze všech výpočetních uzlů. Zálohuje se systémem Legato Net Worker. Podrobnější informace o zálohování a obnově souborů naleznete v kapitole 4.

Prostor domovského adresáře je ale omezen kvótou. Rozlišujeme dva stupně: soft limit a hard limit. V současné době je soft limit standardně nastaven na hodnotu 2GB, hard limit na hodnotu 2,5GB. Hard limit už překročit nelze.

Míru zaplnění adresáře /home a výši limitů lze zjistit po zalogování na ui2 nebo prak3 pomocí příkazu

ssh storage5 /usr/sbin/repquota -s /home

Block limits File limits
User used soft hard grace used soft hard grace
xxx n 1954M 2442M m 0 0

  • n - velikost obsazeného prostoru (v kB)
  • block limits - limity omezující obsazený prostor (v MB)
  • file limits - limity omezující počet uložených souborů (tyto limity nejsou nastavené)
  • grace - doba, po kterou může být překročen soft limit (standardní nastavení je 7 dnů)

Zvýšení kvóty

Pokud uživatel potřebuje v adresáři /home větší prostor, může požádat o zvýšení kvóty. Svou žádost náležitě odůvodní a pošle prostřednictvím e-mailu Janu Švecovi nebo Tomáši Koubovi.

2.2 Pracovní adresář /scratch

Na každém výpočetním uzlu je lokální pracovní prostor /scratch. Do tohoto prostoru by se měly ukládat mezivýsledky výpočtů. Při spuštění úlohy se v adresáři /scratch automaticky vytvoří podadresář /pbstmp.cislojobu.golias. Současně se vytvoří proměnná $TMPDIR, která do tohoto adresáře ukazuje. Po skončení úlohy se tento podadresář automaticky smaže. Tímto způsobem se prostor /scratch průběžně promazává. Proto je třeba ve skriptech, kterými se úlohy zadávají do front, používat pro uložení dočasných dat proměnnou $TMPDIR.

ALERT! Na všech výpočetních uzlech jsou v pracovním adresáři /scratch automaticky promazávány všechny soubory, od jejichž posledního přístupu uběhlo více než 10 dní ( atime přesáhl 240 hodin).

Zpět

3. Zadávání úloh

3.1 Typy front

Některé fronty jsou vyhrazené pro speciální projekty (experimenty), pro určité skupiny uživatelů nebo pro speciální typ úloh (interaktivní úlohy apod.). Fronty mají při spuštění úloh různou prioritu. Mohou mít také nastavené různé limity. Např.:

  • maximální počet úloh, které mohou být z dané fronty spuštěné zároveň
  • maximální množství skutečného času, po který může úloha běžet
  • maximální počet uzlů, které může úloha nárokovat
  • maximální množství paměti, kterou může úloha využít.
Při překročení některého z limitů se úloha nespustí nebo je předčasně ukončena.

Původní rozdělení front na farmě Goliáš je následující:

  • fronty experimentů (atlas, d0, alice, star, auger, ... )
  • fronty pro uživatele ze Sekce vysokých energií FZÚ nezařazených v jiných projektech (fronty long a short)
  • fronty pro uživatele ze Sekce materiálový výzkum, t.j. pro uživatele subclusteru David (fronty solid a isolid)
  • fronty testovací (test, lcgtest ... ).

Fronty experimentů se dále dělí na fronty produkční a fronty neprodukční. Experimenty podporované gridovým projektem mají ještě fronty, jejichž název začíná lcg. Tyto fronty slouží pouze ke spuštění úloh zadaných přes grid.

Každý experiment tedy má 2 fronty: produkční a neprodukční nebo 4 fronty: 2 fronty negridové a 2 fronty gridové, dále dělené na produkční a neprodukční.

Např. fronty pro experiment atlas

atlas fronta negridová a neprodukční
atlasprod fronta negridová a produkční
lcgatlas fronta gridová a neprodukční
lcgatlasprod fronta gridová a produkční

Priority: Úlohy zadané do produkční fronty mají vyšší prioritu než úlohy zadané do fronty neprodukční. Stejně tak fronta short, určená pro kratší úlohy, které nepoběží déle než 4 hodiny, má vyšší prioritu než fronta long, určená pro úlohy časově náročnější. Tedy v případě, že v obou frontách čekají úlohy, po uvolnění procesoru se nejdříve spustí úloha z fronty s vyšší prioritou. Avšak není to tak jednoduché. Kromě priorit se uplatňují ještě další omezení. Ta by měla zaručit co nejoptimálnější využití farmy. Výjimku tvoří fronty s vyhrazeným počtem procesorů.

Příklad: Fronta q1 má nejvyšší prioritu, fronty q2 a q3 mají vyhrazený počet procesorů a stejnou prioritu. Ve frontě q1 čeká n1 úloh, ve frontě q2 běží m2 úloh a čeká n2 úloh a ve frontě q3 čeká n3 úloh. V okamžiku, kdy se uvolní jeden procesor, systém PBS by spustil úlohu z fronty q1 (nejvyšší priorita), ale vzhledem k tomu, že fronty q2 a q3 ještě nenaplnily svůj počet vyhrazených procesorů, spustí se úloha z fronty q2. Při uvolnění dalšího procesoru se spustí úloha z fronty q3 (stejná priorita). Tento postup se opakuje až do doby, kdy fronty q2 a q3 vyčerpají svůj počet rezervovaných procesorů nebo ve frontách už nečekají další úlohy.

Uživatel zadává svou úlohu do fronty z ui2 nebo z praku3 pomocí příkazu qsub. Nesmí posílat úlohy do front označených lcg a také do front testovacích.

Úplný seznam front lze získat po přihlášení na ui2 nebo prak3 pomocí příkazu

qstat -q

Pozn.: Po instalaci systému LDAP proběhne přeregistrování všech uživatelů, vytvoří se nové uživatelské skupiny a v důsledku toho se také změní současná struktura front.

Zpět

3.2 Příkaz qsub

Úloha (job) je v zásadě skript, který si uživatel předem připraví a potom zadá do fronty pomocí příkazu qsub. Příkaz vrátí Job ID.

qsub -q <jméno fronty> <seznam parametrů> <váš skript>

1234567.golias

Uživatel může specifikovat parametry dvěma způsoby:

  • v příkazu qsub
  • přímo ve svém skriptu

Tabulka nejčastějších parametrů:

Parametr Popis
-q jméno fronty
-I interaktivní úloha, podrobnosti zde
-m zaslání e-mailu, není-li specifikováno, žádný e-mail se neposílá
a (abort) – zpráva o přerušení úlohy
b (begin) – zpráva o spuštění úlohy
e (end) – zpráva o ukončení úlohy
-o kam uložit výstupní soubor stdout ( stdout se automaticky ukládá do adresáře, ze kterého byl spuštěn příkaz qsub )
-e kam uložit chybový soubor stderr ( stderr se automaticky ukládá do adresáře, ze kterého byl spuštěn příkaz qsub )
-l seznam požadavků na výpočetní zdroje

Výpočetní uzly mají vlastnosti popisující jejich architekturu, operační systém, zvláštní vybavení, typ, atd. Uživatel může při zadávání úlohy specifikovat požadavky na zdroje (čas, paměť, ... ) a vlastnosti (architektura, hardware, model) uzlu, které úloha potřebuje. Podrobný popis je uveden v PBSProUserGuide 9.2 . Zde si ve zkratce přiblížíme pouze základní využití této funkcionality systému PBSPro.

Tabulka nejčastějších požadavků úlohy na výpočetní zdroje:

pbs_resources Popis
select počet výpočetních uzlů
ncpus počet procesorů na jednom uzlu
mem velikost fyzické paměti
vmem velikost virtuální paměti
walltime množství skutečného času
cput množství času CPU

Ostatní dostupné zdroje a vlastnosti (dále jen resources) je možné vypsat pomocí příkazu pbsnodes. Při zadávání úlohy pomocí příkazu qsub pak uživatel přepínačem -l definuje požadované resources, nejčastěji přes tzv. chunky (anglicky chunks). Chunk je seznam požadovaných resources a jejich hodnot, které jsou úloze alokovány z jednoho uzlu. Kromě obsahu chunku uživatel při zadávání úlohy specifikuje i jejich počet N následujícím způsobem:

-l select=[N:] chunk [+[N:] chunk ...]

Pokud N není uvedeno, dosadí se automaticky hodnota 1. Samotný chunk pak tvoří jeden nebo více výrazů, oddělených dvojtečkou, ve tvaru <resource_name=hodnota>.

-l select=N:<resource_name1=hodnota1>:<resource_name2=hodnota2> ...

Kromě tzv. per-chunk limitů, které úloha požaduje na jeden výpočetní uzel, rozlišujeme ještě tzv. job-wide limity, které požaduje úloha jako celek. Ty jsou v příkazu qsub vypsány samostatně s parametrem -l, tzn. nezařazují se do chunků. Mezi tyto požadavky patří např. walltime a cput.

-l <resource_name=hodnota>

Příklady:

qsub -q <jméno fronty> -l <seznam požadavků na výpočetní zdroje> <váš skript>

Chceme rezervovat Specifikace parametru -l
1 uzel a 1 procesor -l select=1:ncpus=1
1 uzel a 4 procesory -l select=1:ncpus=4
1 uzel typu bl35p se 2 procesory -l select=1:ncpus=2:model=bl35p
1 uzel typu dl140 s dvěma procesory a 2 uzly typu bl35p s 64bitovým OS -l select=1:ncpus=2:model=dl140+2:model=bl35p:bits=64bit
2 uzly, na každém 1 procesor -l select=2:ncpus=1
2 uzly, na jednom 2 procesory, na druhém 4 procesory -l select=1:ncpus=2+1:ncpus=4
1 uzel a 1 procesor na 100 hodin skutečného času -l walltime=100:00:00 -l select=1:ncpus=1

Je možné požadovat i konkrétní uzel pomocí resource vnode. To se ale nedoporučuje, protože čekací doba na spuštění úlohy může být v takovém případě velmi dlouhá.

ALERT! V nové verzi PBSPro 9.2 se nedoporučuje používat starší syntaxi specifikace parametru -l ve tvaru -l nodes= ... :ppn= ... . Měla by se používat novější syntaxe pomocí chunků ve tvaru -l select= ... :ncpus= ... . Zadání pomocí starší verze systém převede do verze novější, ale není zaručeno, že úloha proběhne v pořádku. V žádném případě se nesmí kombinovat obě dvě syntaxe.

ALERT! Kvůli efektivnějšímu fungování fairshare (automatické přidělování výpočetních zdrojů na základě propočítaného času) byly u všech výpočetních uzlů nastaveny multiplikátory, kterými je násoben jednak cput - čas, který úloha zabrala na daném procesoru, jednak walltime - skutečný čas, po který úloha obsazovala výpočetní uzel. Multiplikátory vyjadřují poměr výkonu daného výpočetního uzlu vůči referenci, kterou je stroj typu dl140. Proto hodnoty cput a walltime uvedené v informacích o dané úloze ( příkaz qstat ) neodpovídají skutečným hodnotám. Je třeba si je příslušným multiplikátorem přepočítat. Přehled multiplikátorů pro různé typy strojů je uveden v následující tabulce.

Typ stroje golias Počet CPU Velikost RAM Velikost multiplikátoru
lp1000r golias01 - golias30 2 1GB 0.61
dl140 golias34 - golias79, 95, 96, 99 2 2GB 1
dl140-ht golias80 - golias94 4 4GB 0.6
bl35p Opteron 275 golias101 - golias110 4 8GB 1.44
bl35p Opteron 280 golias111 - golias136 4 8GB 1.76
bl20p Xeon 5160 golias138 - golias142 4 10GB 2.3
bl460c Xeon 5160 golias144 - golias150 4 8GB 2.29
bl465c Opteron 2220 golias151 - golias162 4 8GB 2.3

ALERT! Důležité upozornění !!! Systém PBS používá pro přenášení výsledků z výpočetních uzlů zpět na server, odkud byla úloha zadána, scp. Pro korektní fungování scp je nutné, aby všechny skripty, které se spouští po přihlášení uživatele (např. .bashrc ), neprodukovaly žádný výstup na obrazovku.

Zpět

3.3 Další užitečné příkazy PBS

  • qdel - vymaže úlohu z fronty

qdel <číslo úlohy>

  • qstat - zobrazí dostupné informace o dané úloze, o dané frontě

qstat -f <číslo úlohy> zobrazí podrobné informace o dané úloze
qstat -a <jméno fronty> zobrazí všechny úlohy v dané frontě
qstat -au <ID uživatele> zobrazí všechny úlohy daného uživatele
qstat -q zobrazí všechny fronty na farmě Goliáš

Podrobnější informace najdete na manuálových stránkách

man qstat

Zpět

4. Zálohování a obnova dat

4.1 Zálohování dat

Zálohují se pouze data na svazku /home systémem Legato Net Worker (Produkt firmy EMC pro zálohování rozsáhlé sítě s velkým množstvím dat. Pracuje na principu klient-server). Zálohy se zapisují na pásky o velikosti 400 GB (bez komprese), v současné době jsou vyhrazeny 3 pásky. Každou noc se provádí inkrementální záloha a jednou za měsíc plná záloha. Uchováváme 4 verze plných záloh, tj. data jsou přístupná s minimálně 3 měsíční historií.

4.2 Obnova dat

Obnova ztracených dat se provádí ze stroje storage5 příkazem nwrecover. Program se nastaví do adresáře, z něhož je zavolán.

V případě, že chcete obnovit smazaný soubor, musíte se přihlásit na ui2 nebo prak3 pomocí ssh -X a potom se už bez hesla zalogovat na storage5

ssh storage5

a zadat příkaz

nwrecover &

Dostanete grafické GUI k obnově. Objeví se dvě okna: v levém okně je strom adresářů, v pravém seznam souborů daného adresáře a v horní liště menu. Pomocí volby

Change -> Browse Time...

zvolte datum zálohy dřívější, než kdy byl už soubor smazán, a potvrďte OK. Soubor můžete vyhledávat pomocí volby Search . Klikněte na soubor ("políčko zčerná") a volbou

Mark

označte (modré zaškrtnutí). Pokud chcete soubor uložit do jiného adresáře než do původního, použijte volbu

Options -> Relocate...

zadejte jméno adresáře a potvrďte OK. Spusťte obnovu volbou

Start

Soubor je možné přímo přepsat nebo uložit pod pozměněným jménem. Program možnosti nabídne v dalším okně.

Najednou lze obnovit i více souborů (všechny označené modrým zaškrtnutím) nebo celý adresář.

Obnova je snažší, pokud si pamatujete jméno souboru a přibližné datum, kdy jste soubor naposledy editovali.

Zpět

5. Práce s certifikátem

5.1 Získání certifikátu

Certfikát lze získat od certifikační autority CESNETu, o osobní certifikát se žádá zde.

5.2 Převod do jiných formátů

Certfikát je typicky uložen do internetového prohlížeče. Exportem certifikátu získáme soubor s příponou p12. Pro použití v gridovém prostředí je třeba ho převést do formátu pem příkazy:

openssl pkcs12 -clcerts -nokeys -in usercert.p12 -out usercert.pem

openssl pkcs12 -nocerts -in usercert.p12 -out userkey.pem

Zpět

-- JanaUhlirova - 01 Jul 2008

Edit | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r22 < r21 < r20 < r19 < r18 | More topic actions
 
Powered by TWiki
This site is powered by the TWiki collaboration platformCopyright &Š by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback