Jan
FEB
Mar
26
2008
2009
2010
1 capture
26 Feb 09 - 26 Feb 09
Close
Help
E
dit
A
ttach
P
rintable
r22 - 20 Nov 2008 - 09:51:29 -
JanaUhlirova
You are here:
TWiki
>
VS Web
>
VsDokumentace
>
VsGolias
#MyAnchor ---+!! 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í: %X% Dne 19.11.2008 byl definitivně vypnut server __prak2.farm.particle.cz__. ---++!! Ke stažení * Uživatelský manuál [[http://hpv2.farm.particle.cz/PBSProUserGuide9.2.pdf][ _PBSProUserGuide9.2_ ]] * Administrátorský manuál [[http://hpv2.farm.particle.cz/PBSProAdminGuide9.2.pdf][ _PBSProAdminGuide9.2_ ]]. ---++!! %BLACK%Obsah:%ENDCOLOR% %TOC% ---++ 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_. [[#MyAnchor][Zpět]] ---+++ 1.2 Nový uživatel Každý nový zájemce o používání farmy Goliáš musí vyplnit [[http://www.particle.cz/farm/htmlpages/forusers/ucet_form.pdf][Žá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 _%BROWN%passwd%ENDCOLOR%_ 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. [[#MyAnchor][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 [[#MyAnchor2][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 %BROWN% _ssh storage5 /usr/sbin/repquota -s /home_ %ENDCOLOR% ||| 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_. %X% 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). [[#MyAnchor][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 [[#MyAnchor1][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 %BROWN% _qstat -q_ %ENDCOLOR% _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. [[#MyAnchor][Zpět]] #MyAnchor1 ---+++ 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_. %BROWN% _qsub -q %ENDCOLOR% <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 [[http://www-hep2.fzu.cz/twiki/bin/view/VS/VsFAQ#Jak_se_zad_v_interaktivn_loha][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 [[http://hpv2.farm.particle.cz/PBSProUserGuide9.2.pdf][ _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: _%BROWN%-l select=%ENDCOLOR%[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>_. _%BROWN%-l select=N:%ENDCOLOR%<resource_name1=hodnota1>%BROWN%:%ENDCOLOR%<resource_name2=%ENDCOLOR%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_. _%BROWN%-l %ENDCOLOR%<resource_name=hodnota>_ *Příklady:* _%BROWN%qsub -q %ENDCOLOR%<jméno fronty> %BROWN%-l %ENDCOLOR%<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á. %X% V nové verzi _PBSPro 9.2_ se nedoporučuje používat starší syntaxi specifikace parametru -l ve tvaru %BROWN%-l nodes= ... :ppn= ... %ENDCOLOR%. Měla by se používat novější syntaxe pomocí chunků ve tvaru %BROWN%-l select= ... :ncpus= ... %ENDCOLOR%. 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. #MyAnchor3 %X% 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 [[#MyAnchor2][ _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 | %X% *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. [[#MyAnchor][Zpět]] ---+++ 3.3 Další užitečné příkazy PBS * __qdel__ - vymaže úlohu z fronty %BROWN% _qdel %ENDCOLOR%<číslo úlohy>_ #MyAnchor2 * __qstat__ - zobrazí dostupné informace o dané úloze, o dané frontě | %BROWN% _qstat -f %ENDCOLOR%<číslo úlohy>_ | zobrazí podrobné informace o dané úloze | | %BROWN% _qstat -a %ENDCOLOR%<jméno fronty>_ | zobrazí všechny úlohy v dané frontě | | %BROWN% _qstat -au %ENDCOLOR%<ID uživatele>_ | zobrazí všechny úlohy daného uživatele | | %BROWN% _qstat -q %ENDCOLOR%_ | zobrazí všechny fronty na farmě Goliáš | Podrobnější informace najdete na manuálových stránkách _%BROWN%man qstat%ENDCOLOR%_ [[#MyAnchor][Zpět]] #MyAnchor2 ---++ 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í %BROWN% _ssh -X_ %ENDCOLOR% a potom se už bez hesla zalogovat na _storage5_ %BROWN% _ssh storage5_ %ENDCOLOR% a zadat příkaz %BROWN% _nwrecover &_ %ENDCOLOR% 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 %BROWN% _Change -> Browse Time..._ %ENDCOLOR% 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 %BROWN% _Search_ %ENDCOLOR%. Klikněte na soubor ("políčko zčerná") a volbou %BROWN% _Mark_ %ENDCOLOR% označte (modré zaškrtnutí). Pokud chcete soubor uložit do jiného adresáře než do původního, použijte volbu %BROWN% _Options -> Relocate..._ %ENDCOLOR% zadejte jméno adresáře a potvrďte OK. Spusťte obnovu volbou %BROWN% _Start_ %ENDCOLOR% 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. [[#MyAnchor][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á [[http://www.cesnet.cz/pki/cs/ch-personal.html][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: %BROWN% _openssl pkcs12 -clcerts -nokeys -in usercert.p12 -out usercert.pem_ %ENDCOLOR% %BROWN% _openssl pkcs12 -nocerts -in usercert.p12 -out userkey.pem_ %ENDCOLOR% [[#MyAnchor][Zpět]] -- FZU.JanaUhlirova - 01 Jul 2008
E
dit
|
A
ttach
|
P
rintable
|
V
iew topic
|
Backlinks:
We
b
,
A
l
l Webs
|
H
istory
: r22
<
r21
<
r20
<
r19
<
r18
|
M
ore topic actions
VS
Log In
or
Register
VS Web
Create New Topic
Index
Search
Changes
Notifications
Statistics
Preferences
Webs
ATLAS
AUGER
FZU
ILC
Sandbox
TWiki
VS
Copyright &Š by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki?
Send feedback