HPC
Auto-generated book for HPC
- NIIF_szuperszámítógép_szolgáltatás
- Access_Policy
- HPC-GYIK
- NIIF_szuperszámítógépek_használata
- Intel_Xeon_Phi
- Privacy_Policy
- HPC-Portal
- SSH_kulcs_generálás
- PRACE_User_Support
- Budapest2_klaszter
- Miskolc_UV_2000
- Debrecen2_Phi_klaszter
- HPC_software
- HPC_vizualizacio
- Debrecen2_GPU_klaszter_en
- HPC
- HPC_felhasznaloi_alapelvek
- HPC_konyvtarak
- Debrecen2_GPU_klaszter
NIIF_szuperszámítógép_szolgáltatás
A KIFÜ (Kormányzati Informatikai Fejlesztési Ügynökség) megújult szuperszámítógép szolgáltatása tudományos számítási feladatok futtatására, valamint tudományos célú adattárolásra szolgál. A jelenleg integrált szuperszámítógép-rendszer komponensei négy helyszínen találhatók:
- Debreceni Egyetem
- KIFÜ telephely
- Pécsi Tudományegyetem
- Szegedi Tudományegyetem
A tudományos számítási feladatok különböző típusainak minél szélesebb körű lefedettsége érdekében az egyes helyszíneken különböző felépítésű gépek találhatók: egy helyszínen SMP/ccNUMA, három helyszínen pedig fat-node fürtözött megoldás. Az alrendszereket KIFÜ nagy sávszélességű, alacsony késleltetésű HBONE+ adathálózatán keresztül, ARC grid köztesréteg, valamint harmonizált felhasználói azonosítás segítségével integráljuk egységes elvek mentén elérhető számítási egységgé. Az erőforrás jelenleg Magyarország legnagyobb tudományos számítás céljára felhasználható erőforrása, amely összesen 50 TFlops teljesítményre képes.
A rendszerhez regisztrációt követően, minden olyan személy vagy kutatócsoport hozzáférhet, amely tagintézményi szerződéses kapcsolatban áll a KIFÜ-vel. A gépen megtalálhatók és futtathatók a legkorszerűbb fejlesztőeszközök és tudományos számításra szolgáló alkalmazások, valamint, a KIFÜ adatközpontban elhelyezett alrendszer kivételével, valamennyi alrendszer kiegészül a számítási feladatok eredményeit megjelenítő vizualizációs eszközökkel.
A szuperszámítógép-rendszert a KIFÜ Alkalmazás-fejlesztési és Üzemeltetési Osztálya végzi, amely elérhető a szuper@niif.hu címen.
Általános ismertető
A magyar felsőoktatási, kutatási és közgyűjteményi (a továbbiakban akadémiai) szuperszámítógép-rendszer a HBONE+ Projekt keretén belül került beszerzésre. Ez Magyarország jelenleg legnagyobb teljesítményű, közel 50 Tflop/s összesített számítási kapacitású szuperszámítógépes rendszere. A KIFÜ több mint 10 éves tapasztalattal rendelkezik e téren, hiszen az ország első szuperszámítógép központját 2001-ben adtuk a hazai kutatói közösség számára használatba. Az ilyen eszközök beszerzési ára és üzemeltetése azonban olyan költséges, hogy rendszerint egy-egy intézmény önállóan nem képes azt finanszírozni így célszerűen központi, sok intézmény számára elérhető módon kell a szolgáltatást megvalósítani. Ez a KIFÜ Szuperszámítógép Központ alapvető célja és feladata.
Üzemeltetés
A szuperszámítógép-rendszert a KIFÜ munkatársai üzemeltetik, a KIFÜ számítóközpontjában, valamint három, konvergencia régióban található egyetemen. A szuperszámítógépek üzeme 7x24 órás, azaz folyamatos az év minden napján. Karbantartás céljából, előre bejelentett időpontokban a szolgáltatás szünetelhet.
A szuperszámítógépeket profi, képzett szakembergárda üzemelteti, akik a gép működtetésén túl felhasználói támogatást is biztosítanak. Az üzemeltető mindent megtesz a rendszer folyamatos, zavartalan üzeme és elérhetősége érdekében. Mindazonáltal a gépek működésében vagy elérhetőségében esetlegesen bekövetkező kiesés, illetve a teljesítmény időleges lecsökkenése, file-ok, adatok megsérülése, elveszése által okozott közvetlen vagy közvetett károkért vagy hátrányokért semminemű felelősséget nem vállal.
A felhasználás alapelvei
A szuperszámítógép-rendszer nagy értékű és rendkívül nagy teljesítményű, ám mégis korlátozott erőforrás. Ez azt jelenti, hogy körültekintően kell gazdálkodni a kapacitásával, hiszen az alapvető célt, azt, hogy az akadémiai körben minden valódi igényt ki lehessen elégíteni, csak így lehet elérni.
Ki használhatja a szuperszámítógépet? A szuperszámítógép-rendszert felhasználói a magyar akadémiai körből, azon belül is a KIFÜ tagintézményi köréből kerülhetnek ki. A szuperszámítógépek tényleges felhasználói ezen intézmények munkatársai ill. hallgatói, valamint - indokolt esetben - egy KIFÜ tagintézmény és egy magyar vagy külföldi nem KIFÜ tagintézmény közötti tudományos kooperáció esetén a nem KIFÜ tagintézmény munkatársai lehetnek. Speciális esetben, egyéb indokokra való tekintettel (pl. nagy jelentőségű, az ország számára kiemelten fontos kutatás/fejlesztés/alkalmazás stb.) a fenti szabály alól a KIFÜ vezetése egyedi elbírálás alapján felmentést adhat.
Mire használható a szuperszámítógép-rendszer? A szuperszámítógép üzemeltetésének célja a magyar kutatás és felsőoktatás nagysebességű ill. kapacitású számítási igényeinek kiszolgálása. A gépek tehát felhasználhatók az alkalmazására jogosult intézmények bármelyikében folyó olyan kutatási és/vagy oktatási célra, amelyhez ilyen teljesítményű számítástechnikai kapacitás szükséges. Elsősorban az extrém számítási mennyiséget vagy sebességet igénylő vagy igen nagy memóriaigényű alkalmazások kiszolgálása a cél.
A szuperszámítógépek nem használhatók a fentiektől eltérő célokra (pl. profitérdekelt tevékenység keretében folyó fejlesztésekhez, alkalmazásokhoz, vagy más, hagyományos eszközökkel is kielégítően megoldható feladatokhoz, stb.), vagy hagyományos értelemben vett hálózati szolgáltatások (pl. web-, ftp-, adatbázis- vagy file szerver) üzemeltetésére sem.
Hogyan lehet a szuperszámítógépekhez hozzáférni? A szuperszámítógép-rendszer mindegyik alrendszere a KIFÜ központban, illetve a regionális központokban üzemelnek, ott ahol a magyar akadémiai Internet gerinchálózat (HBONE+) nagysebességű vonalai összefutnak. Az alrendszerek többször 10GB/s sebességű, dedikált lambda-kapcsolatokon keresztül kapcsolódnak egymáshoz, illetve a hálózathoz. Igénybevételük távolról, a hálózaton keresztül lehetséges, tetszőleges kliens számítógépről, alfanumerikus vagy grafikus terminál, ill. terminál emuláció valamint biztonságos kapcsolatot lehetővé tevő protokollok (ssh, scp), köztesréteg felhasználásával. A kitűnő hálózati kapcsolódás biztosítja, hogy a rendszert a gerinchálózat bármelyik pontjáról nagy sebességgel el lehet érni, és így még nagy mennyiségű adat mozgatása sem jelent problémát.
A szuperszámítógép-rendszerhez való hozzáféréshez témaszám(ok)ra van szükség, amit az üzemeltetőtől kell igényelni. A témaszám igényléshez egy kérdőívet kell kitölteni, amelyen megadott információk alapján dönt a KIFÜ az igénylés jogosságáról. Szükség esetén a KIFÜ konzultálhat is az igénylővel mielőtt döntést hoz. A témaszám személyre szóló és át nem ruházható. A témaszám átvételével a felhasználó deklarálja, hogy megismerte, és magára nézve kötelezőnek tartja a szuperszámítógép használatára vonatkozó szabályokat.
Melyek a felhasználás feltételei? A szuperszámítógépeket csak érvényes témaszám birtokában, a témaszám igénylésekor megjelölt feladatokra lehet használni a kapott kvóták keretein belül. A szuperszámítógépek felhasználásával elért tudományos eredmények, tapasztalatok hazai és nemzetközi publikációiban meg kell említeni a KIFÜ infrastruktúra alkalmazásának tényét.
A szuperszámítógépeket felhasználó projektek státuszáról, előrehaladásáról, elért eredményeiről évente legalább egyszer rövid összegzést kell küldeni a KIFÜ-nek.
Hogyan kerülnek elosztásra az erőforrások? A szuperszámítógép erőforrásai (gépidő, processzorszám, memória, háttértár) korlátozottak. Az alapvető cél az, hogy mindenki hozzájusson a számára szükséges kapacitáshoz. Amennyiben egy adott pillanatban az igények meghaladják a rendelkezésre álló kapacitást, úgy a felhasználható kvóták, és az egyes projektekhez rendelt prioritások alapján osztjuk fel az erőforrásokat. A szuperszámítógépen a CPU igényes jobok futtatása helyi ütemező és erőforrás elosztó rendszeren, illetve grid erőforrás brókeren keresztül lehetséges.
Milyen alkalmazások, felhasználói szoftverek ill. fejlesztő eszközök állnak rendelkezésre? A szuperszámítógépeken elérhetők az elterjedt számítógép programozási nyelvek fordítóprogramjai, könyvtárai ill. egyéb fejlesztőeszközei (pl. C, C++, Fortran), a párhuzamos alkalmazások futtatásához szükséges különféle szoftver környezetek (pl. PVM, MPI, OpenMP), egyéb, Linux környezetben használható HPC (High Performance Computing) eszközök, optimalizált párhuzamos matematikai könyvtárak, valamint különféle célalkalmazások.
Milyen felhasználói támogatás/segítség vehető igénybe? A szuperszámítógépek üzemeltetői helpdesk szolgáltatás keretében a gép felhasználói számára szakmai segítséggel, konzultációval, tanácsadással szolgálnak. Szervezünk továbbá a szuperszámítógéppel és felhasználásával kapcsolatos tanfolyamokat, workshopokat és szemináriumokat is. A projekt weboldalai szintén hasznos információkkal szolgálnak.
Mennyit kell fizetni a szuperszámítógépek használatáért? A szuperszámítógépek használata ingyenes a jogosult felhasználók számára.
Témaszám igénylés
A szuperszámítógép használatához témaszámra van szükség. Az alábbi tájékoztató a témaszám igényléshez nyújt segítséget. Kérjük, a témaszám igénylése előtt feltétlenül olvassa el az Általános ismertetőt és a Felhasználói Szabályzatot. Ezek pontosan tájékoztatnak arról, hogy ki, milyen célokra és milyen feltételekkel kaphat témaszámot.
A témaszámokat felhasználói projektekhez rendeljük. Egy projekthez egy vagy több témaszám tartozhat. Témaszámot lehet kérni már bejelentett, futó projekthez, és éppen bejelentendő, új projekthez is. Az új projekt bejelentése az ahhoz tartozó legelső témaszám igénylésével egyidejűleg történik. A KIFÜ minden projekthez egy technikai azonosító számot rendel. Ezt az azonosító számot - ha új projektről van szó - az igénylő a témaszámmal együtt megkapja. Egy már meglévő projekthez kapcsolódó új témaszám igénylésénél meg kell adni a kérdéses projekt technikai számát. Ha egy projekten több munkatárs kíván dolgozni, akkor is mindenki számára külön témaszámot kötelező kérni. Már létező projekt esetén az új témaszám igénylésénél a személyes adatokon túli rész kitöltése helyett a projektre csak hivatkozni kell, annak technikai számával.
Természetesen a projekthez szükséges erőforrásokat csak egyszer kell kérni, a projekt első témaszámának felvételekor ("projekt bejelentés"). A projekthez felvett második és további témaszámok a projekt felhasználói csoportjába fognak tartozni. (A szuperszámítógépen minden projekthez tartozik egy egyedi, UNIX felhasználói csoport így biztosítható az állományok és katalógusok megfelelő védelme.)
A projektet befogadó intézmény ill. szervezeti egység (pl. tanszék, osztály) vezetőjének új projekt bejelentésekor az igénylő kérdőívet alá kell írnia. A projekt vezetőjének a témaszám igénylő lapot minden esetben alá kell írnia. A projekt vezetője (akinek nem szükséges magának is témaszámot kérnie vagy azzal rendelkeznie) felelős azért, hogy a projekthez tartozó témaszámokat rendeltetésszerűen, kizárólag az igényelt célokra használják. Egy témaszám érvényessége a projekt érvényességi idejének lejártáig tart. Egy projekt érvényességi idejére maximum 2 évet lehet kérni, de ez a lejárat előtt meghosszabbítható.
Regisztráció
Kérjük, a témaszám igénylése előtt feltétlenül olvassa el az Általános ismertetőt és a Felhasználói Szabályzatot. Ezek pontosan tájékoztatnak arról, hogy ki, milyen célokra és milyen feltételekkel kaphat témaszámot. A hozzáférés igénylése az alábbi módon, két lépcsőben végezhető:
- Ha a projekt még nincs regisztrálva, töltse ki előbb a projekt regisztrációs űrlapot. A projekt elfogadása esetén (amire egy pár napot lehet, hogy várnia kell, lásd alább), kapni fog egy projekt kódot.
- A projekt kód ismeretében kitöltheti a felhasználói témaszám kérdőíveket az on-line szolgáltatásigénylő rendszerben. A kitöltött, aláírt kérdőíveket nyomtassa ki, és juttassa el a KIFÜ címére személyesen, vagy postai úton.
Az intézet a kinyomtatott, aláírt projektigény kézhezvételétől számított egy héten belül dönt az igény jogosságáról, illetve szükség esetén további információkért megkeresi az igénylőt. A döntés meghozatala után a KIFÜ tájékoztatja az igénylőt és ekkor egyeztetik a témaszám átvételének a módját is.
Access_Policy
Summary of acceptable use policy
The LEO HPC cluster (hereafter referred to as LEO, "cluster", "resources", "system") is used among multiple users in a shared way, thus your actions can have serious impact on the system and can affect other users. The following policies and rules are in place to ensure proper and fair use of the computing resources, as well as to prevent unauthorized or malicious use.
User accountability
LEO users are accountable for their actions. Violations of policy, procedure, and security rules may result in applicable administrative sanctions or legal actions. Users are requested to report any computer security issues and incidents of possible misuse or violation of the account policies to
ugyfelszolgalat@kifu.hu
Resource use
The use of LEO is restricted to academic and research purposes only. Only users affiliated with organisations in partnership with KIFÜ may get accounts. There may be exceptions for this rule in special cases, e.g. an urgent research/development of high impact. Such approval is at the sole discretion of KIFÜ.
Only users with a valid account could use LEO (within the limits of the received quotas) and only for tasks related to their scientific project with which they applied for resources. Users are responsible for using resources in an efficient, effective, ethical, and lawful manner. LEO resources should be used with care to avoid using more capacity than needed. The use of (or the attempt of using) resources beyond the limits of the quotas received is prohibited. The use of resources for personal or private benefit is prohibited. The use of resources to support illegal, fraudulent, or malicious activities is prohibited. Users are required to use resources in accordance with these rules, efficiently, and in a way that does not interfere with or impair the work of other users.
Users are solely responsible for all activities carried out by their account and for the resources made available to them.
In addition to complying with the provisions of this policy users must obey the instructions of the LEO operational team at all times.
Account usage
All accounts on LEO are personal. Users of LEO are not permitted to share their accounts with each other or with persons that do not have an account. To request special data-sharing arrangements among a group of users, you should send a message to
hpc-support@kifu.hu
The access to LEO is permitted only via a secure communication channel (e.g. SSH) to the respective master or gateway login node. Compute nodes are intended for handling heavy computational work and must be accessed via the resource management system (Slurm) only. Direct access to compute nodes is not permitted. It is forbidden to use LEO for activities that are not closely related to the research project. (e.g. e-mail, web browsing etc.) Deployment/operation of network services is also prohibited. Users should not make copies of system configuration files (e.g. the password file) for unauthorized personal use, nor to provide such information to other users or outside personnel.
Software and data
Users should not attempt to access any data or programs contained on the cluster system for which they do not have authorization or explicit consent of the owner of the data/program. Users shall not download, install, or run security-related programs or utilities that reveal weaknesses in the security of the LEO systems. Installation of software on the cluster must include a valid license (if applicable). No software will be installed on the cluster without prior proof of license eligibility. All such information has to be communicated to LEO operation team by sending a message to
hpc-support@kifu.hu
LEO resources should be used to store only data directly related to the research being undertaken by the user on the cluster.
Resources are never to be used for storing any data not directly related to the current research, unless explicitly approved by the LEO operational team.
Data stored on LEO are not subject to backup.
Users are responsible for securing and backing up any data copied to or generated on LEO.
Contact information
If you have any questions about this privacy policy, please contact us by e-mail:
hpc-support@kifu.hu
Changes to the acceptable use policy
The LEO cluster acceptable use policy will be amended and reviewed periodically, and KIFÜ reserves the right to modify and update the present terms whenever deemed necessary, whereas any changes shall become effective after publication on this Access Policy.
HPC-GYIK
Ki használhatja a szuperszámítógépet?
A szuperszámítógép-rendszert felhasználói a magyar akadémiai körből, azon belül is a Kormányzati Informatikai Fejlesztési Ügynökség (KIFÜ) tagintézményei köréből kerülhetnek ki. A szuperszámítógépek tényleges felhasználói ezen intézmények munkatársai ill. hallgatói, valamint - indokolt esetben - egy KIFÜ tagintézmény és egy magyar vagy külföldi nem KIFÜ tagintézmény közötti tudományos kooperáció esetén a nem KIFÜ tagintézmény munkatársai lehetnek. Speciális esetben, egyéb indokokra való tekintettel (pl. nagy jelentőségű, az ország számára kiemelten fontos kutatás/fejlesztés/alkalmazás stb.) a fenti szabály alól a KIFÜ vezetése egyedi elbírálás alapján felmentést adhat.
Mire használható a szuperszámítógép-rendszer?
A szuperszámítógép üzemeltetésének célja a magyar kutatás és felsőoktatás nagysebességű ill. kapacitású számítási igényeinek kiszolgálása. A gépek tehát felhasználhatók az alkalmazására jogosult intézmények bármelyikében folyó olyan kutatási és/vagy oktatási célra, amelyhez ilyen teljesítményű számítástechnikai kapacitás szükséges. Elsősorban az extrém számítási mennyiséget vagy sebességet igénylő vagy igen nagy memóriaigényű alkalmazások kiszolgálása a cél.A szuperszámítógépek nem használhatók a fentiektől eltérő célokra (pl. profitérdekelt tevékenység keretében folyó fejlesztésekhez, alkalmazásokhoz, vagy más, hagyományos eszközökkel is kielégítően megoldható feladatokhoz, stb.), vagy hagyományos értelemben vett hálózati szolgáltatások (pl. web-, ftp-, adatbázis- vagy file szerver) üzemeltetésére sem.
Hogyan lehet a szuperszámítógépekhez hozzáférni?
A szuperszámítógép-rendszer mindegyik alrendszere a KIFÜ központban, illetve KIFÜ regionális központokban üzemelnek, ott ahol a magyar akadémiai Internet gerinchálózat (HBONE+) nagysebességű vonalai összefutnak. Az alrendszerek többször 10GB/s sebességű, dedikált lambda-kapcsolatokon keresztül kapcsolódnak egymáshoz, illetve a hálózathoz. Igénybevételük távolról, a hálózaton keresztül lehetséges, tetszőleges kliens számítógépről, alfanumerikus vagy grafikus terminál, ill. terminál emuláció valamint biztonságos kapcsolatot lehetővé tevő protokollok (ssh, scp), köztesréteg felhasználásával.A kitűnő hálózati kapcsolódás biztosítja, hogy a rendszert a gerinchálózat bármelyik pontjáról nagy sebességgel el lehet érni, és így még nagy mennyiségű adat mozgatása sem jelent problémát.A szuperszámítógép-rendszerhez való hozzáféréshez témaszám(ok)ra van szükség, amit az üzemeltetőtől kell igényelni. A témaszám igényléshez egy kérdőívet kell kitölteni, amelyen megadott információk alapján dönt a KIFÜ az igénylés jogosságáról. Szükség esetén a KIFÜ konzultálhat is az igénylővel mielőtt döntést hoz. A témaszám személyre szóló és át nem ruházható. A témaszám átvételével a felhasználó deklarálja, hogy megismerte, és magára nézve kötelezőnek tartja a szuperszámítógép használatára vonatkozó szabályokat.
Melyek a felhasználás feltételei?
A szuperszámítógépeket csak érvényes témaszám birtokában, a témaszám igénylésekor megjelölt feladatokra lehet használni a kapott kvóták keretein belül.A szuperszámítógépek felhasználásával elért tudományos eredmények, tapasztalatok hazai és nemzetközi publikációiban meg kell említeni a KIFÜ infrastruktúra alkalmazásának tényét.A szuperszámítógépeket felhasználó projektek státuszáról, előrehaladásáról, elért eredményeiről évente legalább egyszer rövid összegzést kell küldeni a KIFÜ-nek.
Hogyan kerülnek elosztásra az erőforrások?
A szuperszámítógép erőforrásai (gépidő, processzorszám, memória, háttértár) korlátozottak. Az alapvető cél az, hogy mindenki hozzájusson a számára szükséges kapacitáshoz. Amennyiben egy adott pillanatban az igények meghaladják a rendelkezésre álló kapacitást, úgy a felhasználható kvóták, és az egyes projektekhez rendelt prioritások alapján osztjuk fel az erőforrásokat. A szuperszámítógépen a CPU igényes jobok futtatása helyi ütemező és erőforrás elosztó rendszeren, illetve grid erőforrás brókeren keresztül lehetséges.
Milyen alkalmazások, felhasználói szoftverek ill. fejlesztő eszközök állnak rendelkezésre?
A szuperszámítógépeken elérhetők az elterjedt számítógép programozási nyelvek fordítóprogramjai, könyvtárai ill. egyéb fejlesztőeszközei (pl. C, C++, Fortran), a párhuzamos alkalmazások futtatásához szükséges különféle szoftver környezetek (pl. MPI, OpenMP, CUDA), egyéb, Linux környezetben használható HPC (High Performance Computing) eszközök, optimalizált párhuzamos matematikai könyvtárak, valamint különféle célalkalmazások.
Milyen felhasználói támogatás/segítség vehető igénybe?
A szuperszámítógépek üzemeltetői helpdesk szolgáltatás keretében a gép felhasználói számára szakmai segítséggel, konzultációval, tanácsadással szolgálnak. Szervezünk továbbá a szuperszámítógéppel és felhasználásával kapcsolatos tanfolyamokat, workshopokat és szemináriumokat is. A projekt weboldalai szintén hasznos információkkal szolgálnak.
Mennyit kell fizetni a szuperszámítógépek használatáért?
A szuperszámítógépek használata ingyenes a jogosult felhasználók számára.
A köszönetnyilvánítást milyen formában javasolt megtenni a publikációban?
Angol nyelvű tudományos publikációkban a következő köszönetnyilvánítást javasoljuk: We acknowledge [KIFÜ] for awarding us access to resource based in Hungary at [Budapest/Debrecen/Pécs/Szeged]. Where technical support has been received the following additional text should also be used: The support of [name of person/people]from Governmental Information Technology Development Agency (GITDA), Hungary to the technical work is gratefully acknowledged.
NIIF_szuperszámítógépek_használata
A szuperszámítógépekről
A KIFÜ szuperszámítógép szolgáltatása tudományos számítási feladatok futtatására, valamint tudományos célú adattárolásra szolgál. A jelenleg integrált szuperszámítógép-rendszer komponensei négy helyszínen találhatók:
- Debreceni Egyetem
- KIFÜ központ
- Pécsi Tudományegyetem
- Szegedi Tudományegyetem
A tudományos számítási feladatok különböző típusainak minél szélesebb körű lefedettsége érdekében az egyes helyszíneken különböző felépítésű gépek találhatók: egy helyszínen ccNUMA, három helyszínen pedig "fat-node" fürtözött megoldás. Az alrendszereket a KIFÜ nagy sávszélességű, alacsony késleltetésű HBONE+ adathálózatán keresztül, ARC grid köztesréteg, valamint harmonizált felhasználói azonosítás segítségével integráljuk egységes elvek mentén elérhető számítási egységgé. Az erőforrás jelenleg Magyarország legnagyobb tudományos számítás céljára felhasználható erőforrása, amely összesen 50 billió lebegőpontos művelet elvégzését teszi lehetővé másodpercenként. A szuperszámítógép-rendszert a KIFÜ üzemelteti és fejleszti. A rendszerhez regisztrációt követően, minden olyan személy vagy kutatócsoport hozzáférhet, amely tagintézményi szerződéses kapcsolatban áll a KIFÜ-vel. A gépen megtalálhatók és futtathatók a legkorszerűbb fejlesztőeszközök és tudományos számításra szolgáló alkalmazások, valamint, a KIFÜ adatközpontban elhelyezett alrendszer kivételével, valamennyi alrendszer kiegészül a számítási feladatok eredményeit megjelenítő vizualizációs eszközökkel.
Köszönetnyilvánítás
Tudományos publikációkban a következő köszönetnyilvánítást javasoljuk:
We acknowledge KIFÜ for awarding us access to resource based in Hungary.
Where technical support has been received the following additional text should also be used:
The support of [name of person/people] from KIFÜ, Hungary to the technical work is gratefully acknowledged.
Hozzáférés a szuperszámítógépekhez
A témában több videót is készítettünk, amelyek bemutatják a hozzáférés menetét (kulcsgenerálás és hozzáférés) és a filefeltöltés gyakorlati tutoriál keretében Windows operációs rendszeren.
A fenti videók tartalmazhatnak elavult információkat pl. az ütemezővel kapcsolatban, a jelenlegi ütemező használatához külön videóanyagot ajánljunk.
A szuperszámítógépekhez kulcsos SSH használatával lehet hozzáférni. Ajánlott UTF-8 képes terminált használ az ékezetes betűk megjeelenítése érdekében. PUTTY terminál esetén a Window/Translation beállítás alatt a character set-et kell UTF-8-ra állítani.
SSH belépés
ssh USER@login.SITE.hpc.niif.hu
ahol a USER
a felhasználónév, a SITE
pedig a belépéshez használt szupergép neve: budapest, debrecen, pecs, szeged. Nem alapértelmezett kulcs használata a -i KULCS
kapcsolóval lehetséges.
Belépés a szegedi gépre alice felhasználóként, az SSH privát kulcsot a keys/szeged
fájlból olvasva:
ssh -i keys/szeged alice@login.szeged.hpc.niif.hu
Fájl másolás SCP segítségével
Letöltés a HOME könyvtárból és feltöltés a HOME könyvtárba:
scp USER@login.SITE.hpc.niif.hu:FILE FILE
scp FILE USER@login.SITE.hpc.niif.hu:FILE
A szegedi gép HOME könyvtárában lévő stuff.tgz
fájl letöltése a helyi gép aktuális könyvtárába:
scp bob@login.szeged.hpc.niif.hu:stuff.tgz .
Adatátvitel rsync segítségével
Nagyobb fájlok ill. könyvtárstruktúrák szinkronizálásához az SSH-t és az rsync-et együtt kell használni. Fel- és leszinkronizálás:
rsync -a -e ssh DIRECTORY USER@login.budapest.hpc.niif.hu:/home/USER
rsync -a -e ssh USER@login.budapest.hpc.niif.hu:/home/USER/DIRECTORY
A budapesti gépre szinkronizálom a helyi src
könyvtár tartalmát (nem az alapértelmezett kulcsot használva) és a másolás folyamatát nyomonkövetem:
rsync -a -h --progress -e "ssh -i keys/budapest" ./src alice@login.budapest.hpc.niif.hu:/home/alice
Felhasználói felület
A szupergépek elsődleges felhasználói felülete a Bash shell. Az automatikusan betöltődő NIIF Common Environment (NCE) a PS1 promptot a következőképp állítja be:
rövid CWD
|
BUDAPEST[login] ~ (0)$
| | |
HPC állomás | |
rövid gép név |
előző parancs exit kódja
Modul környezet
A szupergépekre telepített alkalmazásokat az ún. modul rendszer segítségével lehet használ. A modul rendszer lehetővé teszi egy adott alkalmazás több verziójának használatát is. Feladata a shell környezeti változók helyes beállítása. Normál felhasználók számára az alapértelmezett modul környezet automatikusan betöltődik. Az elérhető modulok listáját a következő paranccsal kapjuk meg:
module avail
a már betöltött modulok listáját:
module list
Alkalmazást a következő paranccsal tölthetünk be:
module load APPS
ahol az APPS
a betöltendő modulok space-szel elválasztott listája.
A NIIF által beállított környezeti változókat nce
parancs listázza ki.
Példa
A Maple, netcfd és az R csomagok betöltése:
module load maple netcdf R
Adatok megosztása projekt tagok számára
Fájlok ill. könyvtárak megosztásához használjuk a [1] (fájlrendszer ACL-eket). Az ACL-ekkel a hagyományos unix engedélyeken felül finoman szabályozhatjuk a fájlok és könyvtárak hozzáférési engedélyeit. Kérjük, hogy fokozottan figyeljenek arra, hogy a teljes $HOME
könyvtárra sose adjanak "rwx" jogot más felhasználóknak, mivel pl. a .ssh
mappa nagyon érzékeny a jogosultságokra, és a rendszer nem fogja beengedni legközelebb a felhasználót! A következő példában a $HOME/Shared
könyvtárat osztjuk egy munkatárs számára:
# a home könyvtár beállítása
# user1 user számára belépsi engedély: u:user1:x
$ setfacl -m u:user1:x $HOME
$ getfacl $HOME
# file: user2/user2
# owner: user2
# group: user2
user::rwx
user:user1:--x
group::r-x
mask::r-x
other::---
# Shared könyvtár megosztása
# user1 számára minden unix jog
$ cd
$ mkdir Shared
$ setfacl -m u:user1:rwx $HOME/Shared
$ getfacl Shared
# file: Shared
# owner: user2
# group: user2
user::rwx
user:user1:rwx
group::rwx
mask::rwx
other::r-x
Python csomag telepítése a saját home könyvtárunkba
Itt egy példa arra, hogy hogyan tudjuk feltelepíteni a mercurial python csomagot.
$ module load python
$ pip install --user mercurial
Közös home könyvtár használata
A szuperszámítógépek login és vserver node-jai osztott home könyvtárral vannak összekötve. Fontos, hogy az osztott könyvtárat a számítási node-ok nem érik el, ezért az osztott home-ot csak tárolásra ill. megosztásra lehet használni. Az osztott terület Debrecenben van, ezért ott a leggyorsabb. A másik három helyen lassabb a hozzáférés a nagyobb távolság miatt. A programok kimenetét továbbra is a lokális scratch vagy home könyvtárba kell írni. Amelyik login node-on használni szeretnénk az osztott home könyvtárat, ott adjuk ki a következő parancsokat:
cd; mkdir shared; ln -s /mnt/fhgfs/home/$USER shared/$USER
Ezek után a $HOME/shared/$USER
könyvtárba másoljuk a megosztott fájlokat. Ez a könyvtár a következő környezeti változóba is exportálódik:
$NCE_SHARED
Biztonsági mentés, adatmegosztás
A következő példa mentést végez a $HOME/data
könyvtárról:
rsync -avuP $HOME/data $NCE_SHARED
Törölje a fájlokat a mentésben is:
rsync -avuP --delete $HOME/data $NCE_SHARED
Alkalmazások lefordítása
Mindenkitől azt kérjük, hogy először próbálja meg saját maga lefordítani az alkalmazását. Ha ez valamilyen oknál fogva mégsem sikerülne, akkor következő lépésként a magyarországi szuperszámítógép felhasználóktól érdemes kérdezni, mert nagy esély van rá hogy mások is belefutottak ugyanabba a problémába. Ezen a címen lehet őket elérni: hpc-forum kukac listserv.niif.hu
. Feliratkozni itt lehet erre a levelezőlistára. Az archívumban is érdemes utánanézni a kérdésnek. A KIFÜ HPC support csak igen korlátozottan képes egyéni fordítási kérésekkel foglalkozni, de problémával felkeresheti a hpc-support kukac niif.hu
címet. Az utóbbi esetben pár napos türelmüket mindenképp kérjük válaszunkig.
SLURM ütemező használata
Weboldal:
A SLURM ütemező bemutatása:
A szupergépeken CPU óra (gépidő) alapú ütemezés működik. Ez azt jelenti, hogy a fogyasztási időtartamra (hónap) az elérhető maximális gépidő fel van osztva a felhasználók között. Minden UNIX felhasználó egy vagy több számlához (Account) tartozhat. Az ütemező számla egy adott HPC-s projekthez tartozik, hasonló a UNIX csoporthoz. Szupergépes feladatokat csak az egyes számlák terhére lehet indítani. A CPU óra az elhasznált idő (Walltime) és az igényelt processzorok számának szorzata. Például a budapesti gépen 2 db node (48 processzor mag) foglalása 30 percre 48 * 30 = 1440 CPU perc = 24 CPU óra. A CPU órát az ütemező a futás kezdetétől a befejezésig méri.
Rendkívül fontos arról meggyőződni, hogy a futtatandó alkalmazás rendesen kihasználja-e a szupergépet. Egy üres vagy rosszul futó job hamar elhasználja a rendelkezésre álló gépidőt. Elfogyasztott gépidő esetén új jobokat már nem lehet indítani, és meg kell várni a számlázási időszak végét. A gépidő limitek (Account Limit) minden hónap elején jóváíródnak.
Számláink állapotáról a következő paranccsal kapunk információt:
sbalance
A parancs a következő táblázatot jeleníti meg. A felhasználó két számlához (foobar,barfoo) is hozzáfér, futatthat a számla terhére. Saját magát megcsillagozva látja a listában. Bobbal mindkét számlán (Account oszlop) Alice is osztozik. A második oszlopban (Usage) az egyes felhasználók elhasznált gépideje, a negyeik oszlopban pedig a számla összesített gépideje látható. Az utolsó két oszlop a maximális (Account Limit) és a még alérhető (Available) gépidőről ad tájékoztatást.
Scheduler Account Balance
---------- ----------- + ---------------- ----------- + ------------- -----------
User Usage | Account Usage | Account Limit Available (CPU hrs)
---------- ----------- + ---------------- ----------- + ------------- -----------
alice 0 | foobar 0 | 0 0
bob * 0 | foobar 0 | 0 0
bob * 7 | barfoo 7 | 1,000 993
alice 0 | barfoo 7 | 1,000 993
A gépidő becslése
Nagyüzemi (production) futtatások előtt gépidőbecslést érdemes végezni. Ehhez a következő parancs használható:
sestimate -N NODES -t WALLTIME
ahol a NODES
a lefoglalni kívánt node-ok száma, a WALLTIME
pedig a futás maximális ideje.
Fontos, hogy a lefoglalni kívánt gépidőt a lehető legpontosabban adjuk meg, mivel az ütemező ez alapján is rangsorolja a futtatásra váró feladatokat. Általában igaz, hogy a rövidebb job hamarabb sorra kerül. Érdemes minden futás idejét utólag az sacct
paranccsal is ellenőrizni.
Alice 2 nap 10 órára és 2 node-ra szeretne foglalást kérni, megnézi van-e elég gépidő a számláján:
sestimate -N 2 -t 2-10:00:00
Estimated CPU hours: 2784
Sajnos ebben a hónapban erre már nem telik.
Állapotinformációk
Az ütemezőben lévő jobokról az squeue
, a klaszter általános állapotáról az sinfo
parancs ad tájékoztatást. Minden beküldött jobhoz egy egyedi azonosítószám (JOBID) rendelődik. Ennek ismeretében további információkat kérhetünk. Feladott vagy már futó job jellemzői:
scontrol show job JOBID
Minden job egy ún. számlázási adatbázisba (accounting) is bekerül. Ebből az adatbázisból visszakereshetők a lefuttatott feladatok jellemzői és erőforrás-felhasználás statisztikái. A részletes statisztikát a következő paranccsal tudjuk megnézni:
sacct -l -j JOBID
A felhasznált memóriáról a következő parancs ad tájékoztatást:
smemory JOBID
A lemezhasználatról pedig a
sdisk JOBID
Slurm figyelmeztető üzenetek
Resources/AssociationResourceLimit - Erőforrásra vár
AssociationJobLimit - Nincs elég CPU idő vagy a maximális CPU szám le van foglalva
Piority - Alacsony prioritás miatt várakozik
Az utóbbi esetben, csőkkenteni kell a job által lefoglalni kívánt időt. Egy adott projekt részére maximálisan 512 CPU-n futhatnak jobok egy adott időben.
Az ütemezőben 3 feladat van. Az első egy arrayjob, éppen erőforrásra vár (PENDING). A második egy MPI job, ami 4 node-on fut már 25 perce (TIME). A harmadik egy egy node-os OMP futtatás, éppen most indult el. A feladatik nevei (NAME) egyénileg adható meg. Rövid, informatív neveket érdemes adni.
squeue -l
Wed Oct 16 08:30:07 2013
JOBID PARTITION NAME USER STATE TIME TIMELIMIT NODES NODELIST(REASON)
591_[1-96] normal array alice PENDING 0:00 30:00 1 (None)
589 normal mpi bob RUNNING 25:55 2:00:00 4 cn[05-08]
590 normal omp alice RUNNING 0:25 1:00:00 1 cn09
Ennek a 2 node-os batch jobnak a jellemző memóriaterhelés a következő volt: kb. 10GB virtuális és 6.5GB RSS memóriát használt el node-onként.
smemory 430
MaxVMSize MaxVMSizeNode AveVMSize MaxRSS MaxRSSNode AveRSS
---------- -------------- ---------- ---------- ---------- ----------
10271792K cn06 10271792K 6544524K cn06 6544524K
10085152K cn07 10085152K 6538492K cn07 6534876K
CPU felhasználás ellenőrzése
Nagyon fontos meggyőződni arról, hogy az alkalmazás kihasználja-e a rendelkezésre álló gépidőt. Egy futó alkalmazás a következő paranccsal tudunk monitorozni:
sjobcheck JOBID
Ez a job 4 node-on fut. A LOAD csoport a gép általános terheléséről ad információt és kb. a core-ok számával egyezik meg. A helyes felhasználásról a CPU csoport ad tájékoztatást. Ideális esetben a User
oszlop értékei 90 fölött vannak. Ez alatt valamilyen probléma lépett fel és a futást érdemes megszakítani.
Hostname LOAD CPU Gexec
CPUs (Procs/Total) [ 1, 5, 15min] [ User, Nice, System, Idle, Wio]
cn08 24 ( 25/ 529) [ 24.83, 24.84, 20.98] [ 99.8, 0.0, 0.2, 0.0, 0.0] OFF
cn07 24 ( 25/ 529) [ 24.93, 24.88, 20.98] [ 99.8, 0.0, 0.2, 0.0, 0.0] OFF
cn06 24 ( 25/ 529) [ 25.00, 24.90, 20.97] [ 99.9, 0.0, 0.1, 0.0, 0.0] OFF
cn05 24 ( 25/ 544) [ 25.11, 24.96, 20.97] [ 99.8, 0.0, 0.2, 0.0, 0.0] OFF
Licenszek ellenőrzése
Az elérhető és éppen használt licenszekről a következő parancs ad információt:
slicenses
Karbantartás ellenőrzése
A karbantartási időablakban az ütemező nem indít új jobokat, de beküldeni lehet. A karbantartások időpontjairól a következő parancs ad tájékoztatást:
sreservations
Összesített felhasználás
Egy hónapra visszamenőleg az elfogyasztott CPU perceket a következő paranccsal kérhetjük le:
susage
Teljes fogyasztás
Ha szeretnénk tájékozódni arról, hogy egy bizony idő óta mennyi a CPU idő felhasználásunk akkor azt ezzel paranccsal tudjuk lekérdezni:
sreport -t Hours Cluster AccountUtilizationByUser Accounts=niif Start=2014-01-01
niif helyett a saját projektünk azonosítóját kell megadni.
Feladatok futtatása
Alkalmazások futtatása a szupergépeken kötegelt (batch) üzemmódban lehetséges. Ez azt jelenti, hogy minden futtatáshoz egy job szkriptet kell elkészíteni, amely tartalmazza az igényelt erőforrások leírását és a futtatáshoz szükséges parancsokat. Az ütemező paramétereit (erőforrás igények) a #SBATCH
direktívával kell megadni. Az ütemezők összehasonlításáról és a Slurm-ban elérhető direktívákról a következő táblázat ad bővebb tájékoztatást.
Kötelező paraméterek
A következő paramétereket minden esetben meg kell adni:
#!/bin/bash
#SBATCH -A ACCOUNT
#SBATCH --job-name=NAME
#SBATCH --time=TIME
ahol az ACCOUNT
a terhelendő számla neve (elérhető számláinkről az sbalance
parancs ad felvilágosítást), a NAME
a job rövid neve, a TIME
pedig a maximális walltime idő (DD-HH:MM:SS
). A következő időformátumok használhatók:
"minutes", "minutes:seconds", "hours:minutes:seconds", "days-hours", "days-hours:minutes" és "days-hours:minutes:seconds".
A jobok feladását a következő parancs végzi:
sbatch jobscript.sh
Sikeres feladás esetén a következő kimenetet kapjuk:
Submitted batch job JOBID
ahol a JOBID
a feladat egyedi azonosítószáma.
A feladat leállítását a következő parancs végzi:
scancel JOBID
Nem újrainduló jobok
Nem újrainduló jobokhoz a következő direktívát kell használni:
#SBATCH --no-requeue
Feladat sorok
A szupergépeken két, egymást nem átfedő, sor (partíció) áll rendelkezésre, a test
sor és a prod
sor. Utóbbi az éles számolásokra való, előbbi fejlesztés és tesztelés céljára használható. A teszt sorban összesen 1 node-ot, maximum fél órára lehet lefoglalni. Az alapértelmezett sor a prod
. A teszt partíciót a következő direktívával lehet kiválasztani:
#SBATCH --partition=test
A szolgáltatás minősége (QOS)
A szolgáltatást alapértelmezett minősége normal
, azaz nem megszakítható a futás.
Magas prioritás
A magas prioritású jobok maximum 24 óráig futhatnak, és kétszer gyorsabb időelszámolással rendelkeznek, cserébe az ütemező előreveszi ezeket a feladatokat.
#SBATCH --qos=fast
Alacsony prioritás
Lehetőség van alacsony prioritású jobok feladására is. Az ilyen feladatokat bármilyen normál prioritású job bármikor megszakíthatja, cserébe az elhasznált gépidő fele számlázódik csak. A megszakított jobok automatikusan újraütemeződnek. Fontos, hogy olyan feladatokat indítsunk alacsony prioritással, amelyek kibírják a véletlenszerű megszakításokat, rendszeresen elmentik az állapotukat (checkpoint) és ebből gyorsan újra tudnak indulni.
#SBATCH --qos=lowpri
Memória foglalás
A memória a CPU-hoz hasonlóan korlátozott, foglalható erőforrás. A felhasználás mérése a memória / core alapon történik: 1 core óra, 2600 MB órának felel meg. Alapértelmezetten 1 CPU core-hoz 1000 MB memória van rendelve, ennél többet a következő direktívával igényelhetünk:
#SBATCH --mem-per-cpu=MEMORY
ahol MEMORY
MB egységben van megadva. Budapesten és Szegeden a maximális memória/core 2600 MB.
Email értesítés
Levél küldése job állapotának változásakor (elindulás,leállás,hiba):
#SBATCH --mail-type=ALL
#SBATCH --mail-user=EMAIL
ahol az EMAIL
az értesítendő emial cím.
Tömbfeladatok (arrayjob)
Tömbfeladatokra akkor van szükségünk, egy szálon futó (soros) alkalmazást szeretnénk egyszerre sok példányban (más-más adatokkal) futtatni. A példányok számára az ütemező a SLURM_ARRAY_TASK_ID
környezeti változóban tárolja az egyedi azonosítót. Ennek lekérdezésével lehet az arrayjob szálait elkülöníteni. A szálak kimenetei a slurm-SLURM_ARRAY_JOB_ID-SLURM_ARRAY_TASK_ID.out
fájlokba íródnak. Az ütemező a feltöltést szoros pakolás szerint végzi. Ebben az esetben is érdemes a processzorszám többszörösének választani a szálak számát. Bővebb ismertető
Alice felhasználó a foobar számla terhére, maximum 24 órára ad fel 96 db soros jobot. A #SBATCH --array=1-96
direktíva jelzi, hogy tömbfeladatról van szó. Az alkalmazást az srun
paranccsal kell indítani. Ebben az esetben ez egy shell szkript.
#!/bin/bash
#SBATCH -A foobar
#SBATCH --time=24:00:00
#SBATCH --job-name=array
#SBATCH --array=1-96
srun envtest.sh
Soros (serial) jobok
Több soros job futtatását a tömbfeladatokhoz hasonlóan kell indítani.
A következő példában a test sorban 3 egy szálon dutó programot indítunk el. A programok és az inputok lehetnek különbözőek. Fontos, hogy az utolsó parancsot nem kell a háttérben (&) indítani és a wait-tel kell befejezni a job szkriptet.
#!/bin/bash
#SBATCH --job-name=serial
#SBATCH --time=24:30:00
#SBATCH -n 3
#SBATCH --partition=test
srun -n 1 program input1 &
srun -n 1 program input2 &
srun -n 1 program input3
wait
OpenMPI feladatok
MPI feladatok esetén meg kell adnunk az egy node-on elinduló MPI processzek számát is (#SBATCH --ntasks-per-node=
). A leggyakoribb esetben ez az egy node-ban található CPU core-ok száma. A párhuzamos programot az mpirun
paranccsal kell indítani.
Bob felhasználó a barfoo számla terhére 2 node-ot, 12 órára foglal le egy MPI job számára. Az egyes node-okon 24 MPI szálat fog elindítani. A program stdout kimenetét a slurm.out
fájlba irányítja (#SBATCH -o
).
#!/bin/bash
#SBATCH -A barfoo
#SBATCH --job-name=mpi
#SBATCH -N 2
#SBATCH --ntasks-per-node=24
#SBATCH --time=12:00:00
#SBATCH -o slurm.out
mpirun ./a.out
SGI ccNUMA UV 1000 (Pécs)
A pécsi gépen legalább 6 szálon működő jobok futtatása lehetságes. Az egyetlen elfogadott paraméter a szálak szám (-n
), amelynek 6 többszörösének kell lenni. Ezen a gépen nincs teszt sor. Kérjük, hogy 48-nál kevesebb szálon futó programokat az UV-n ne futtassanak! Egy szálú ill. array jobok futtatása nem lehetséges.
OMP Példa
#!/bin/bash
#SBATCH -A barfoo
#SBATCH --job-name=omp
#SBATCH -n 48
#SBATCH --time=03:00:00
#SBATCH -o slurm.out
/opt/nce/bin/numainfo
OMP_NUM_THREADS=$SLURM_NTASKS ./a.out
SGI MPT MPI Példa
#!/bin/bash
#SBATCH -A barfoo
#SBATCH --job-name=omp
#SBATCH -n 48
#SBATCH --time=03:00:00
#SBATCH -o slurm.out
/opt/nce/bin/numainfo
mpirun $SLURM_NTASKS ./a.out
Jobok monitorozása
CPU használat:
smonitor -n <JOBID>
Memória használat:
smonitor -m <JOBID>
Ütemezés sor foglaltsága:
sinfo_uv
SGI MPT MPI feladatok (Debrecen)
MPI feladatok esetén meg kell adnunk az egy node-on elinduló MPI processzek számát is (#SBATCH --ntasks-per-node=
). A leggyakoribb esetben ez az egy node-ban található CPU core-ok száma. A párhuzamos programot az mpirun
paranccsal kell indítani. Az SGI MPT MPI paraméterezése kicsit más, mint az OpenMPI. Debrecen az SGI MPT az alpértelmezett MPI környezet!
Bob felhasználó a barfoo számla terhére 2 node-ot, 12 órára foglal le egy MPI job számára. Az egyes node-okon 24 MPI szálat fog elindítani. A program stdout kimenetét a slurm.out
fájlba irányítja (#SBATCH -o
).
#!/bin/bash
#SBATCH -A barfoo
#SBATCH --job-name=mpi
#SBATCH -N 2
#SBATCH --ntasks-per-node=12
#SBATCH --time=12:00:00
#SBATCH -o slurm.out
source /opt/nce/bin/machines
export MPI_OPT="${MACHINES} -np ${SLURM_NTASKS_PER_NODE}"
mpirun ${MPI_OPT} ./a.out
SGI PerfBoost egyéb MPI feladatokra (Debrecen)
Az SGI MPT lehetőséget ad arra, hogy nem MPT MPI-vel fordított MPI programok is használjunk. Ebben az esetben az MPI hívások MPT hívásokkal cserélődnek ki.
Egy OpenMPI-re fordított program indítása:
#!/bin/bash
#SBATCH -A barfoo
#SBATCH --job-name=mpi
#SBATCH -N 2
#SBATCH --ntasks-per-node=12
#SBATCH --time=12:00:00
#SBATCH -o slurm.out
source /opt/nce/bin/machines
export MPI_OPT="${MACHINES} -np ${SLURM_NTASKS_PER_NODE}"
mpirun ${MPI_OPT} perfboost -ompi ./a.out
CPU binding
Az MPI programok teljesítménye általában javítható a processzek CPU magokhoz kötésével. Ilyenkor a párhuzamos program szálait az operációs rendszer nem ütemezi a CPU magok között, ezért javulhat a memória lokalizáció (kevesebb cache miss). A kötés használata ajánlott. Tesztekkel meg kell győződni, hogy egy adott alkalmazás esetén melyik kötési stratégia adja a legjobb eredményt. A következő beállítások az OpenMPI környezetre vontakoznak. A kötésekről részletes információt a --report-bindings
MPI opcióval kaphatunk. Az indítási parancsok melett a részletes binding információ néhány sora is látható. Fontos, hogy az ütemező task binding-ját nem kell használni!
Kötés CPU magonként
Ebben az esetben az MPI szálak (rank) sorban töltik fel a CPU magokat.
Indítási parancs: mpirun --bind-to-core --bycore
[cn05:05493] MCW rank 0 bound to socket 0[core 0]: [B . . . . . . . . . . .][. . . . . . . . . . . .]
[cn05:05493] MCW rank 1 bound to socket 0[core 1]: [. B . . . . . . . . . .][. . . . . . . . . . . .]
[cn05:05493] MCW rank 2 bound to socket 0[core 2]: [. . B . . . . . . . . .][. . . . . . . . . . . .]
[cn05:05493] MCW rank 3 bound to socket 0[core 3]: [. . . B . . . . . . . .][. . . . . . . . . . . .]
Kötés CPU foglalat szerint
Ebben az esetben az MPI szálak váltakozva töltik fel a CPU-kat.
Indítási parancs: mpirun --bind-to-core --bysocket
[cn05:05659] MCW rank 0 bound to socket 0[core 0]: [B . . . . . . . . . . .][. . . . . . . . . . . .]
[cn05:05659] MCW rank 1 bound to socket 1[core 0]: [. . . . . . . . . . . .][B . . . . . . . . . . .]
[cn05:05659] MCW rank 2 bound to socket 0[core 1]: [. B . . . . . . . . . .][. . . . . . . . . . . .]
[cn05:05659] MCW rank 3 bound to socket 1[core 1]: [. . . . . . . . . . . .][. B . . . . . . . . . .]
Kötés node-ok szerint
Ebben az esetben az MPI szálak váltakozva töltik fel a node-okat. Lagalább 2 node foglalása szükséges.
Indítási parancs: mpirun --bind-to-core --bynode
[cn05:05904] MCW rank 0 bound to socket 0[core 0]: [B . . . . . . . . . . .][. . . . . . . . . . . .]
[cn05:05904] MCW rank 2 bound to socket 0[core 1]: [. B . . . . . . . . . .][. . . . . . . . . . . .]
[cn06:05969] MCW rank 1 bound to socket 0[core 0]: [B . . . . . . . . . . .][. . . . . . . . . . . .]
[cn06:05969] MCW rank 3 bound to socket 0[core 1]: [. B . . . . . . . . . .][. . . . . . . . . . . .]
OpenMP (OMP) feladatok
OpenMP párhuzamos alkalmazásokhoz maximum 1 node-ot lehet lefoglalni. Az OMP szálák számát az OMP_NUM_THREADS
környezeti változóval kell megadni. A változót vagy az alkamazás elé kell írni (ld. példa), vagy exportálni kell az indító parancs előtt:
export OMP_NUM_THREADS=10
A következő példában egy taskhoz 10 CPU core-t rendeltunk, a 10 CPU core-nak egy node-on kell lennie. A CPU core-ok számát a SLURM_CPUS_PER_TASK
változó tartalmazza, és ez állítja be az OMP szálak számát is.
Alice felhasználó a foobar számla terhére, maximum 6 órára indít el egy 10 szálas OMP alkalmazást.
#!/bin/bash
#SBATCH -A foobar
#SBATCH --job-name=omp
#SBATCH --time=06:00:00
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=10
OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK ./a.out
Hibrid MPI-OMP feladatok
Hibrid MPI-OMP módról akkor beszélünk, ha a párhuzamos alkalmazás MPI-t és OMP-t is használ. Érdemes tudni, hogy az Intel MKL-el linkelt programok MKL hívásai OpenMP képesek. Általában a következő elosztás javasolt: az MPI processzek száma 1-től az egy node-ban található CPU foglalatok száma, az OMP szálak ennek megfelelően az egy node-ban található összes CPU core szám vagy annak fele, negyede (értelem szerűen). A jobszkipthez a fenti két mód paramétereit kombinálni kell.
A következő példában 2 node-ot, és node-onként 1-1 taskot indítunk taskonként 24 szállal. Alice felhasználó a foobar számla terhére, 8 órára, 2 node-ra küldött be egy hibrid jobot. Egy node-on egyszerre csak 1 db MPI processz fut ami node-onként 24 OMP szálat használ. A 2 gépen összesen 2 MPI proceszz és 2 x 24 OMP szál fut.
#!/bin/bash
#SBATCH -A foobar
#SBATCH --job-name=mpiomp
#SBATCH --time=08:00:00
#SBATCH -N 2
#SBATCH --ntasks=2
#SBATCH --ntasks-per-node=1
#SBATCH --cpus-per-task=24
#SBATCH -o slurm.out
export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK
mpirun ./a.out
Maple Grid feladatok
Maple-t az OMP feladatokhoz hasonlóan 1 node-on lehet futtatni. Használatához be kell tölteni a maple modult is. A Maple kliens-szerver üzemmódban működik ezért a Maple feladat futtatása előtt szükség van a grid szerver elindítására is (${MAPLE}/toolbox/Grid/bin/startserver
). Ez az alkalmazás licensz köteles, amit a jobszkriptben meg kell adni (#SBATCH --licenses=maplegrid:1
). A Maple feladat indátását a ${MAPLE}/toolbox/Grid/bin/joblauncher
paranccsal kell elvégezni.
Alice felhasználó a foobar számla terhére, 6 órára indítja el a Maple Grid alkalmazást:
#!/bin/bash
#SBATCH -A foobar
#SBATCH --job-name=maple
#SBATCH -N 1
#SBATCH --ntasks-per-node=24
#SBATCH --time=06:00:00
#SBATCH -o slurm.out
#SBATCH --licenses=maplegrid:1
module load maple
${MAPLE}/toolbox/Grid/bin/startserver
${MAPLE}/toolbox/Grid/bin/joblauncher ${MAPLE}/toolbox/Grid/samples/Simple.mpl
Matlab feladatok
Ez az alkalmazás licensz köteles, amit a jobszkriptben meg kell adni (#SBATCH --licenses=matlabdce:1,matlabdct:1,matlab:1
). Összesen 96 darab
Distributed Computing Server, 13 darab Distributed Computing Toolbox és 13 Matlab licensz lett megvásárolva.
#!/bin/bash
#SBATCH -A foobar
#SBATCH --job-name="Matlab test job"
#SBATCH -n 1
#SBATCH --licenses=matlabdce:1,matlabdct:1,matlab:1
#SBATCH -o slurm.out
matlab -nodisplay < job.m
GPU-k használata
A szegedi szuperszámítógép rendelkezik 2db GPU kártyákkal is felszerelt compute node-dal. A GPU node-okban 2x6db Nvidia Tesla M2070-es kártya található. A GPU-s node-ok külön job sorban található (--partition gpu
). A GPU-k számát a --gres gpu:#
direktívával kell megadni.
Alice felhasználó a foobar számla terhére, 4GPU-n, 6 órára indítja a következő jobot.
#!/bin/bash
#SBATCH -A foobar
#SBATCH --job-name=GPU
#SBATCH --partition gpu
#SBATCH --gres gpu:4
#SBATCH --time=06:00:00
$PWD/gpu_burnout 3600
Alkalmazások beállításai
Saját programok telepítése
A saját fordítású programokat a HOME könyvtáradba kell telepíteni, ezt általában a fordítás előtti lefuttatott configure szkripttel lehet beállítani. Az adott program a $HOME/local alá fog települni. A PATH és egyéb környezeti változókat értelem szerűen kell beállítani.
cd $HOME
mkdir local
(belépés az alklamazás könyvtárába)
./configure --prefix=$HOME/local
make; make install
A frontend gépeken felhasználói limitek vannak beállítva. Ezekről a következő paranccsal kapunk információt:
ulimit -a
A limitek a compute node-okon és az UV-n nincsenek beállítva.
Java JVM heap méret
A memória limit miatt a Java virtuális gépen és fordító nem jól működik, ezért meg kell adni a maximális heap méretét:
java -Xmx512m -version
javac -J-Xmx512m -version
vagy exportálni kell a következő változót:
export _JAVA_OPTIONS="-Xms1g -Xmx1g"
Python Numpy és Scipy használat
A numerikus Python használatához a következő csomagokat kell betölteni:
module load python numpy scipy
A numpy és a scipy csomagok az Intel MKL OpenMP gyorsítását használják. A jobokat az openmp
párhuzamos környezetbe kell elküldeni.
HP Budapest
Fordítás
Elérhető fordítók listája
Forító | Soros | Párhuzamos |
---|---|---|
Intel Fortran | ifort | mpiif90 |
Intel C | icc | mpiicc |
GNU Fortran | gfotran | mpif90 |
GNU C | gcc | mpicc |
A fordítási paramétereket az NCE környezeti változókból érdemes kiolvasni:
NCE_OFLAGS - optimalizációs kapcsolók C és Fortran
NCE_FFLAGS - Fortran kapcsolók
NCE_CFLAGS - C kapcsolók
NCE_LDFLAGS - könyvtárak C és Fortran
Az NCE környezeti változó listáját az nce
paranccsal kérhetjük le.
A budapesti gépen elérhető a PRACE környezet is, amely tartalmaz egy ajánlott kapcsoló és könyvtár összeállítást tartalmaz. A PRACE környezet betöltése:
module load prace
A PRACE környezet az AMD ACML matematikai könyvtárakat használja, amennyiben az Intel MKL-re van szükségünk, akkor a PRACE környezetet nem kell betölteni. A megfelelő MKL kapcsolókat az Intel Link Advisor szerint kell beállítani, pl.:
FFLAGS=-openmp -I$(MKLROOT)/include
CFLAGS=-openmp -I$(MKLROOT)/include
LDFLAGS=$(MKLROOT)/lib/intel64/libmkl_scalapack_lp64.a \
-Wl,--start-group \
$(MKLROOT)/lib/intel64/libmkl_intel_lp64.a \
$(MKLROOT)/lib/intel64/libmkl_intel_thread.a \
$(MKLROOT)/lib/intel64/libmkl_core.a \
$(MKLROOT)/lib/intel64/libmkl_blacs_openmpi_lp64.a \
-Wl,--end-group -lpthread -lm
Párhuzamos környezet
OpenMP
Az OpenMP paraméterket környezeti változókon keresztül kell beállítani. Az openmp
párhuzamos SLURM környezet az OpenMP szálak számát beállítja. Tovább környezeti változókat az LLNL OpenMP oldalán találtok.
MPI
Az alapértelmezett MPI könyvtár az Open MPI. Ajánlott optimalizációs kapcsolók (CPU binding):
--bind-to-core --bycore
SGI ICE Debrecen
Az alapértelmezett MPI könyvtár az SGI MPT. A felhasználói programokat ehhez a könyvtárhoz érdemes fordítani. Ajánlott fordítás opciók:
MPI fordítási opciók
CFLAGS=-O2 -xSSE4.2
FFLAGS=-O2 -xSSE4.2
LDFLAGS=$(MKLROOT)/lib/intel64/libmkl_scalapack_lp64.a \
-Wl,--start-group $(MKLROOT)/lib/intel64/libmkl_intel_lp64.a \
$(MKLROOT)/lib/intel64/libmkl_sequential.a \
$(MKLROOT)/lib/intel64/libmkl_core.a \
$(MKLROOT)/lib/intel64/libmkl_blacs_sgimpt_lp64.a -Wl,--end-group \
-lpthread -lm
MPI és OpenMP fordítási opciók
Ebben az esetben az MKL műveletek OpenMP szálasíthatók, a program hibrid MPI és OMP módban is tud üzemelni.
CFLAGS=-O2 -xSSE4.2 -openmp
FFLAGS=-O2 -xSSE4.2 -openmp
LDFALGS=$(MKLROOT)/lib/intel64/libmkl_scalapack_lp64.a \
-Wl,--start-group $(MKLROOT)/lib/intel64/libmkl_intel_lp64.a \
$(MKLROOT)/lib/intel64/libmkl_intel_thread.a \
$(MKLROOT)/lib/intel64/libmkl_core.a \
$(MKLROOT)/lib/intel64/libmkl_blacs_sgimpt_lp64.a -Wl,--end-group \
-liomp5 -lpthread -lm -openmp
ARC köztesréteg
Ez a NorduGrid közösség által fejlesztett Grid köztesréteg. Részletes dokumentációkért ezt a weboldalt érdemes felkeresni.
Miért is használjuk?!
- Jobb terhelés elosztást tesz lehetővé a szuperszámítógépek között
- A jobok azon a gépen fognak elindulni, ami a legmegfelelőbb a számára
- Egy nagy egységgé kapcsolja össze a szuperszámítógépeket
- Szabványos webservice interfésszel (OGSA-BES, HPC Basic Profile) rendelkezik. Ezáltal könnyen lehet integrálni más rendszerekkel
- Nagyon sok operációs rendszert támogat
- A saját számítógépünkről tudjuk kezelni a szuperszámítógépes jobokat
- A futás idejű környezetek használatával a megfelelő módon lefordított alkalmazást tudjuk használni és nem kell észben tartani, hogy éppen melyik szuperszámítógépen van telepítve a program
Grid tanúsítvány igénylése
Első lépésként szükségünk lesz egy Grides X.509 tanúsítványra, amivel az ARC klienseket használni tudjuk. A HPC portálon keresztül lehetőségünk van igényelni egy 2 hétig érvényes SLCS tanúsítványt. A személyes adatok menüpontra kell kattintani és az oldal végén lesz az igénylő felület. Fontos: legalább egy HPC projekt tagsággal rendelkeznünk kell a HPC portálon. Itt található az a letölthető UNIX script is, ami minden szükséges beállítást elvégez a számunkra:
$ chmod +x slcs_unix_install.sh
$ ./slcs_unix_install.sh
$HOME/.globus/usercert.pem and $HOME/.globus/userkey.pem installed
NIIF HPC SLCS Root CA installed: $HOME/.globus/certificates/SLCSCA.pem
Default ARC client configuration created: $HOME/.arc/client.conf
NIIF Root CA 2 installed: $HOME/.globus/certificates/NIIFCA.pem
$
Az SLCS másik nagy előnye az egyszerűsített igénylésen kívül az, hogy 1 órán belül az összes szuperszámítógépen automatikusan engedélyezve lesz. Viszont ha nem szeretnénk minden második héten új X.509-es tanúsítványt igényelni, akkor lehetőség van arra is, hogy 1 évig érvényes IGTF tanúsítványt igényeljünk a KIFÜ-től ezen az oldal keresztül. Ebben az esetben a [mailto:hpc-support@niif.hu] címre kell elküldenünk az IGTF-es tanúsítványunk publikus részét és meg kell adnunk, hogy melyik témaszámunkhoz legyen majd rendelve a szuperszámítógépeken.
ARC kliensek használatba vétele
Telepítés
A csomagok telepítéséhez az itt leírt repo-kat lehet használni: http://download.nordugrid.org/repos-15.03.htmld Fontos: 5.0-ás ARC verziót telepítsük.
Debian alapú rendszerek esetén:
apt-get install nordugrid-arc-client
Redhat alapú rendszerek esetén:
yum install nordugrid-arc-client
OSX csomag telepítése brew segítségével:
brew install nordugrid-arc
Ha nem találtunk megfelelő csomagot, akkor innen le tudjuk tölteni a forráskódját és le tudjuk fordítani.
Konfigurálás
$HOME/.arc/client.conf:
[common]
[computing/budapest]
url=https://login.budapest.hpc.niif.hu:60000/arex
infointerface=org.nordugrid.wsrfglue2
submissioninterface=org.ogf.bes
default=yes
[computing/szeged]
url=https://login.szeged.hpc.niif.hu:60000/arex
infointerface=org.nordugrid.wsrfglue2
submissioninterface=org.ogf.bes
default=yes
[computing/debrecen]
url=https://login.debrecen.hpc.niif.hu:60000/arex
infointerface=org.nordugrid.wsrfglue2
submissioninterface=org.ogf.bes
default=yes
[computing/pecs]
url=https://login.pecs.hpc.niif.hu:60000/arex
infointerface=org.nordugrid.wsrfglue2
submissioninterface=org.ogf.bes
default=yes
# FastestQueue – ranks targets according to their queue length
brokername=FastestQueue
# Random – ranks targets randomly
#brokername=Random
# Data – ranks targets according the amount of megabytes of the requested input files that are already
# in the computing resources cache.
#brokername=Data
# PythonBroker:<module>.<class>[:arguments] – ranks targets using any user-supplied custom
# Python broker module, optionally with broker arguments. Such module can reside anywhere in
# user’s PYTHONPATH
#brokername=PythonBroker
[alias]
pecs=computing:ARC1:https://login.pecs.hpc.niif.hu:60000/arex
szeged=computing:ARC1:https://login.szeged.hpc.niif.hu:60000/arex
debrecen=computing:ARC1:https://login.debrecen.hpc.niif.hu:60000/arex
budapest=computing:ARC1:https://login.budapest.hpc.niif.hu:60000/arex
hp=budapest szeged
sgi=pecs debrecen
Érdemes beállítani, hogy alapértelmezés szerint a FastestQueue brókert használja, ezáltal mindig arra a szuperszámítógépre fogja küldeni a jobokat, ahol a legkevesebb a várakozó jobok száma. A konfigurációs fájl részletes dokumentációját és az ARC kliensek leírásait itt lehet megnézni.
Grid proxy készítése
Ha már telepítettük a tanúsítványunkat és az ARC klienseket akkor a következő lépés az, hogy egy proxy tanúsítványt kell készítenünk, ami alapértelmezés szerint 12 óráig érvényes.
$ arcproxy
Enter pass phrase for private key:
Your identity: /C=HU/O=NIIF/OU=SLCS/L=hpcteszt/CN=joe
Proxy generation succeeded
Your proxy is valid until: 2015-03-30 05:01:09
$
Tesztelési célból ezeket a parancsokat érdemes kipróbálni:
$ arcinfo -c szeged
$ arcinfo -c hp -l
$ arcinfo
Grid job készítése
A jobok leírására több formátumot is használhatunk: JSDL, vagy xRSL. Így adjuk meg, hogy a jobunknak mire van szüksége. Itt egy példa job:
$ cat job.xrsl
&
(executable="matlab.sh")
(arguments="matlab.m")
(stdout="stdout.txt")
(stderr="stderr.txt")
(jobname="Matlab test")
(inputFiles=
("matlab.m" "")
)
(memory>="1000")
(gmlog="gm.log")
(wallTime="240")
(runTimeEnvironment="APPS/MATH/MATLAB-7.13")
$ cat matlab.sh
#!/bin/bash
echo
echo "Compute node: " `/bin/hostname -f`
echo
matlab -nodisplay < $1
$ cat matlab.m
2+3
Ennél a példánál a APPS/MATH/MATLAB-7.13 futásidejű környezetet kértük, ezáltal ez a job csak azon a szuperszámítógépen fog elindulni, ahol ez telepítve van. Továbbá azt kértük még, hogy 240 percig futhasson és legalább 1000 MByte memória rendelkezésre álljon.
Az arcinfo -l paranccsal tudjuk megnézni, hogy a szuperszámítógépeken milyen futás idejű környezetek (runtime environment-ek) vannak telepítve. Ha szeretnénk egy új környezet beállíttatni, akkor ide kell levelet küldeni.
OpenMP példa
Job elkészítése:
$ cat job-openmp.xrsl
&
(executable="omp_mm")
(stdout="stdout.txt")
(stderr="stderr.txt")
(jobname="OpenMP test")
(queue="test")
(executables="omp_mm")
(count="10")
(countpernode="10")
(environment=("OMP_NUM_THREADS" "10"))
(queue="test")
(inputFiles=
("omp_mm" "")
)
(memory>="2600")
(gmlog="gm.log")
(wallTime="20")
Job elküldése:
$ arcsub job-openmp.xrsl
Job submitted with jobid: https://login.debrecen.hpc.niif.hu:60000/arex/cpbNDmLzXwlng5dCemyuQPMmABFKDmABFKDmyVNKDmWBFKDmDQBwOn
Job állapotának a lekérdezése:
$ arcstat https://login.debrecen.hpc.niif.hu:60000/arex/cpbNDmLzXwlng5dCemyuQPMmABFKDmABFKDmyVNKDmWBFKDmDQBwOn
Job: https://login.debrecen.hpc.niif.hu:60000/arex/cpbNDmLzXwlng5dCemyuQPMmABFKDmABFKDmyVNKDmWBFKDmDQBwOn
Name: OpenMP test
State: Finished
Exit Code: 0
Status of 1 jobs was queried, 1 jobs returned information
Job letöltése:
$ arcget https://login.debrecen.hpc.niif.hu:60000/arex/cpbNDmLzXwlng5dCemyuQPMmABFKDmABFKDmyVNKDmWBFKDmDQBwOn
Results stored at: cpbNDmLzXwlng5dCemyuQPMmABFKDmABFKDmyVNKDmWBFKDmDQBwOn
Jobs processed: 1, successfully retrieved: 1, successfully cleaned: 1
zion:~ joe $ cd cpbNDmLzXwlng5dCemyuQPMmABFKDmABFKDmyVNKDmWBFKDmDQBwOn
zion:cpbNDmLzXwlng5dCemyuQPMmABFKDmABFKDmyVNKDmWBFKDmDQBwOn joe $ ls -l
total 16
drwx------ 12 joe staff 408 Mar 29 21:24 gm.log
-rw------- 1 joe staff 0 Mar 29 21:24 stderr.txt
-rw------- 1 joe staff 6362 Mar 29 21:24 stdout.txt
zion:cpbNDmLzXwlng5dCemyuQPMmABFKDmABFKDmyVNKDmWBFKDmDQBwOn joe $
Adatok ellenőrzése:
zion:cpbNDmLzXwlng5dCemyuQPMmABFKDmABFKDmyVNKDmWBFKDmDQBwOn joe $ head stdout.txt
Starting matrix multiple example with 10 threads
Initializing matrices...
Thread 0 starting matrix multiply...
Thread=0 did row=0
Thread 9 starting matrix multiply...
Thread 6 starting matrix multiply...
Thread=0 did row=1
Thread 5 starting matrix multiply...
Thread=5 did row=50
Thread=5 did row=51
zion:cpbNDmLzXwlng5dCemyuQPMmABFKDmABFKDmyVNKDmWBFKDmDQBwOn joe$
MPI példa
$ cat job-mpi.xrsl
&
(executable="mpi.sh")
(stdout="stdout.txt")
(stderr="stderr.txt")
(jobname="MPI test")
(executables="connectivity" "mpi.sh")
(count="10")
(inputFiles=
("connectivity" "")
("mpi.sh" "")
)
(memory>="2600")
(gmlog="gm.log")
(wallTime="20")
(runTimeEnvironment>=ENV/GCC/MPI/OPENMPI-1.4.3)
$ cat mpi.sh
#!/bin/bash
mpirun -np 10 ./connectivity -v
Grafikus felületű ARC kliens
Parancssoros klienseken kívül használni lehet még grafikus klienseket is. Innen tudják letölteni őket.
Intel_Xeon_Phi
Az oldalon található információk segítséget nyújtanak a HPC felhasználóinknak, hogy alkalmazásaikat miként portolhatják valamint optimalizálhatják a hatékonyabb futást szem előtt tartva Intel Xeon Phi koprocesszor kártyákon.
!!! info
Egy 10 alkalmas, angol nyelvű Xeon Phi programozás tutoriál videóanyaggal és példaprogrammal elérhető a [Colfax oldalán](http://colfaxresearch.com/how-16-04/)
Hardver bemutatása
Intel® Xeon Phi™ Coprocessor 7120P
CPU | threads/Core | max threads | CPU Freq | Memória | L1 cache | L2 cache | Interfész | Ptot | Számítási kapacitás |
---|---|---|---|---|---|---|---|---|---|
61 | 4 Hardver | 244 | 1238 GHz | 16GB GDDR5 | 32KB/core | 512KB/core | PCIe | 300W | 1,2 TFlop/s dupla pontosság |
OpenMP-nél csak 240 | ~100 cycles ~174 GB/s | ~3 cycles | ~10 cycles | ~7 GB/s ~1 microsecond | 2,4 TFlop/s egyszeres pontosság |
Az Intel® 1. generációs Xeon Phi™ koprocesszorában található 61 processzor ugyanazt a 16GB memóriát éri el, de semmilyen módon se fér hozzá közvetlenül a hoszt gép fizikai memóriájához. Budapest2 és Debrecen3-Phi gépeinkben számítási nodonként 2-2 Phi™ koprocesszor található. A kártyákon speciális célú Linux kernel fut melyre a belépés limitáltan csak a rendszergazdák számára lehetséges SSH-n keresztül a hoszt gépről. Természetesen a kártyára belépve olyan érzésünk lehet, mintha egy sok processzoros gépen dolgoznánk, ami rendelkezik rengeteg memóriával. Ez így is van, de a hatékonyabb kihasználás érdekében az SSH-n keresztüli elérés nem lehetséges, csak a Slurm segítségével valamint a programozási nyelvek által támogatott csatornákon keresztül. Ennek részletezése lentebb megtalálható.
Használati módok
A koprocesszor használatai módjait két csoportba lehet sorolni. A natív és az offload használatot. Ezen használati módokról a lenti fejezetekben több részletet is megtudhat. Az itt megfogalmazott "támogatás" csak a mi infrastruktúránkra érvényes! A bemutatott példák c++ nyelven vannak, de természetesen c és fortran esetén is megtalálható az ekvivalens módszer.
a) nem támogatott mód
közvetlen natív használat
A natív mód arra szolgál, hogy a MIC kártyára lefordított alkalmazásunkat felmásoljuk a kártyára, majd belépünk SSH-n a kártyára és azon futtatjuk a bináris kódunkat. Biztonsági okokból a közvetlen natív használat az NIIF HPC infrastruktúrán nem elérhető.
b) támogatott, de nem preferált használat
automatikus kódátvitel
Ebben az esetben nem kell átmásolnunk a bináris alkalmazásunkat a kártyára sőt még csak be se kell lépnünk, mert ezt a két lépést egy beépített tool végzi el. A tool eléréséhez szükséges parancs neve: micnativeloadex
Ebben az esetben a workflow a következőképpen módosul:
-
Alkalmazás megírása. például hello.cc
-
Alkalmazás fordítása
icpc -o hello-MIC -mmic hello.cc
-
A tool futásához szükséges library-k megadása
export SINK_LD_LIBRARY_PATH=/opt/intel/composerxe-<verzió>/compiler/lib/mic
-
Alkalmazás futtatása
micnativeloadex hello-MIC
BUDAPEST2[cn10] phi (0)$ export SINK_LD_LIBRARY_PATH=/opt/intel/composerxe-2011.4.191/compiler/lib/mic BUDAPEST2[cn10] phi (0)$ micnativeloadex hello-MIC Hello world! I have 244 logical cores. BUDAPEST2[cn10] phi (0)$
intelhome=/opt/intel/compilers_and_libraries_2016.1.150/linux export SINK_LD_LIBRARY_PATH=$intelhome/compiler/lib/mic:$intelhome/mkl/lib/mic
c) támogatott módok
Offload
Az Offload modell esetén szükséges a forráskód módosítása, mégpedig úgy, hogy azon kódrészletet, amit a koprocesszoron szeretnénk futtatni, ki kell egészíteni egy fordítási direktívával. Az alkalmazás fordításakor elegendő csak a CPU-ra való binárist készíteni mivel a modell végzi a megfelelő forrás részlet mozgatását és futtatását.
Példánkban jól látható, hogy a második kiíratás már a koprocesszoron fut.
#include <stdio.h>
int main(int argc, char * argv[]) {
printf("Hello world from host!\n");
#pragma offload target(mic)
{
printf("Hello world from coprocessor!\n"); fflush(stdout);
}
printf("Bye\n");
}
Ebben a példában az operációs rendszer választja ki, hogy melyik Phi kártyán fusson le a kódrészlet. Amennyiben mi szeretnénk explicite megmondani, hogy melyik kártyán fusson, akkor a fordítási direktívában a mic kulcsszó után kell tenni egy ":"-t és a kártya sorszámát [mi esetünkben 0 vagy 1]. Ekkor így nézne ki a direktíva: #pragma offload target(mic:1)
Amennyiben az offload szekcióban függvény hívás is szerepel, akkor szükségeltetik az függvény futásához szükséges változók adatterületének átmásolása a Phi kártyára, majd a lefutás után visszamásolni a hoszt gépre. Ezen másolást az offload_attribute push és pop paraméterei segítségével határozhatjuk meg. A következő mátrix-vektor szorzás példánál az A mátrix globális változó, míg a b és c vektorok a függvény paraméterei.
//A változók felmásolásra kerülnek a Xeon Phi-re
#pragma offload_attribute(push, target(mic))
double* A;
void MatrixVector(double *b, double *c, double m, double n) {
...
c[= A[..](])*b[]
}
// felmásolt objektumok visszamásolása
#pragma offload_attribute(pop)
int main() {
...
#pragma offload target(mic) in(A[0:n*m])
// így is meg lehetne adni: #pragma offload target(mic:0) in(A : length(n*m))
{
MatrixVector(b, c, m, n);
}
...
}
Ekkor minden memória területet 2x kell másolni, egyszer fel a kártyára, majd másodszor vissza a hoszt gépre, pedig elegendő lenne csak az eredmény vektort visszamásolni. Ezen optimalizálással egy későbbi fejezetben foglalkozunk.
Futás során kaphatunk részletes riportot is, hogy pontosan milyen adatmozgatások történnek az alkalmazás futása során. Ehhez nincs szükség másra csak az OFFLOAD_REPORT környezeti változó megfelelő beállítása. A beállított értékek Automatic Offload esetén 1, 2, míg Compiler Assisted Offload esetén 1, 2 és 3 lehetnek, attól függően mennyire részletes riportot szeretnénk kapni. beállítás:
export OFFLOAD_REPORT=3
példa kimenet a hello alkalmazásra:
Hello world from host!
[[MIC 0](Offload]) [File] hello_offload.cc
[[MIC 0](Offload]) [Line] 5
[[MIC 0](Offload]) [Tag] Tag 0
Hello world from coprocessor!
[[HOST](Offload]) [0](Tag) [Time](CPU) 0.554653(seconds)
[[MIC 0](Offload]) [0](Tag) [Data](CPU->MIC) 0 (bytes)
[[MIC 0](Offload]) [0](Tag) [Time](MIC) 0.000140(seconds)
[[MIC 0](Offload]) [0](Tag) [Data](MIC->CPU) 0 (bytes)
Bye
Offload + OpenMP
Amennyiben nem csak 1 processzort szeretnénk használni a Phi kártyánkon és az alkalmazásunkban használt számítás megengedi a párhuzamosítást, akkor az OpenMP segítségével párhuzamosíthatjuk a megfelelő számítást.
Példánk maradjon ugyanúgy a mátrix-vektor szorzás. Amennyiben a teljes kártya adta kapacitást ki szeretnénk használni, akkor az OMP threadek számát 240-re kell beállítani. Azért nem 244-re, mivel 1 CPU-t dedikáltan csak a kommunikációra használ a rendszer és 1 CPU 4 hardver threaddel rendelkezik.
Ekkor a példánk így változik:
#include <omp.h>
#pragma offload_attribute(push, target(mic))
void multiply(int n, int m, double* A, double* b, double* c){
const int nCPUs = omp_get_max_threads(); //240
omp_set_num_threads(nCPUs);
#pragma omp parallel for schedule(dynamic, 1)
for ( int i = 0 ; i < m ; i++)
for ( int j = 0 ; j < n ; j++)
c[+= A[i*n+j](i]) * b[j];
}
#pragma offload_attribute(pop)
int main(){
double * A = (double*) malloc(sizeof(double)*n*m);
...
#pragma offload target(mic) in(A:length(n*m))
multiply(n, m, A, b, c);
Az alkalmazás fordításánál a fordítónak meg kell adni, hogy használhja az openmp library-ket is. Ezt a -qopenmp kapcsolóval tudjuk elérni.
icpc -o matrix-CPU -qopenmp matrix.cc
MPI + Offload + OpenMP
Abban az esetben, ha 1 számítási node nem elég, MPI segítségével össze tudunk kötni több nodet, heterogén rendszert alkotva, és azokon alkalmazható a fenti Offload + OpenMP modell.
Phi használat slurm-mel
Slurm esetén a mic opciót kell megadni a gres-knél. Amennyiben egynél több kártyára van szükség, akkor azt a mic:2-vel lehetséges megadni. Ekkor két kártyát foglal le az ütemező a futtatandó feladatnak. Egy lehetséges feladat, amit srun-nal lehet a slurmben beküldeni. debrecen3 esetén a prod-phi particiót kell használni
$ cat slurm_job_openmp_phi
#!/bin/bash
#SBATCH -A <PROJECT NEVE>
#SBATCH --job-name=<JOB NEVE>
#SBATCH --gres mic:2
#SBATCH --time=1:00:00
#SBATCH --partition=prod
#SBATCH -o slurm-%A.out
export OMP_NUM_THREADS=2
./runme_openmp_2phi
Ekkor a feladat beküldése a következő paranccsal lehetséges.
srun ./slurm_job_openmp_phi
Alkalmazások optimalizálása a kártyára
Ebben a fejezetben optimalizálási lehetőségeket mutatunk be, melyek segítségül szolgálhatnak az egyes alkalmazások hatékonyabb futása érdekében ezzel jobban kihasználni a rendelkezésre álló erőforrások adta számítási kapacitás.
Környezeti változók
Lehetséges csak a Phi kártyákon használt környezeti változók beállítása, amit az alkalmazásunk használni is tud. Példánkban az OpenMP esetén használható szálak számát állíthatjuk be:
export MIC_ENV_PREFIX=XEONPHI
export OMP_NUM_THREADS=12
export XEONPHI_OMP_NUM_THREADS=240
A beállított prefix tetszőleges karaktersorozat lehet, a lényeg, hogy ezt a beállított prefixet használjuk a környezeti változók esetén is!
Hosszredukció
Többnyire a fordítók, ha nem mondjuk meg explicite, a dupla pontosságú változatot választják a lehetséges változó- és függvény típusok közül. Amennyiben a számításunk nem igényli a dupla pontosságot, akkor használjuk a forrásban mindenhol az adott típus vagy függvény egyszeres pontosságú változatát, mellyel jelentős teljesítmény növekedést tudunk elérni. Továbbá az egyes műveletek futási ideje nem egyforma, így a műveletet helyettesíthetjük más művelettel, ami gyorsabb, akkor ismét javíthatunk a hatékonyságon. Íme pár példa, amit alkalmazni lehet:
- "/" művelet helyett "***" -t használjunk, mert azt gyorsabban végre tudja hajtani a processzor
- pow => 1.0 / sqrt() , tetszőleges hatványozás, pl.: 3/2-ik hatvány
- hardver áltatl támogatott műveletek:
- exp => exp2
- log => log2
- dupla pontosság -> egyszeres pontosság lebegőpontos számok és műveletek esetén
- 1.0 => 1.0f
- pow => powf
Vektorizáció
A vektorizáció azon fordítási időben eldönthető optimalizációs faktor, amely nagy mértékben függ attól a hardver felépítésétől, amire éppen a fordítás történni fog. Legfontosabb befolyásoló tényezők a processzor cache méretei illetve a vektor műveletekért felelős aritmetikai egységének jellemzői mivel ezeket használja fel a fordító az optimalizálási folyamata során. Az automatikus vektorizáció minimum -O2 szinttől érvényes, de mivel általában ez a szint az alapértelmezett, ezért minden fordításnál alkalmazásra kerül. A fordító programnak a következő kapcsolókat lehet megadni, melyek segítenek a minél jobb vektorizációban:
- -qopt-report=<szám> ; az optimalizációs jelentés részletességét lehet megadni 0-tól 5-ig, ahol az 5-s szint a legrészletesebbet jelenti
- -qopt-report-phase:vec ; a vektorizációról szeretnék jelentést kapni
- -opt-report-file=<fájlnév> ; megadható a riportfájl neve
icpc autovec.cc -mmic -qopt-report=5 -opt-report-file=vectorization.oMIC.optrpt -qopt-report-phase:vec
SIMD
Az adatok hatékonyabb feldolgozására az egyik megvalósítás a SIMD (Single Instruction Multiple Data), amikor is a különálló adatokat úgy kezeli, mintha az vektorok volnának és azon végzi el a vektor-műveletet. Ezzel egy a hardver által támogatott műveletet végzünk egy lépésben egy nagyobb adatmennyiségen, ezzel párhuzamosítva a feldolgozási folyamatot. Ezzel a módszerrel nagyon jó adat szintű párhuzamosítást lehet elérni.
Főbb támogatott műveletek:
- aritmetikai műveletek, bináris operátorok
- összehasonlítások
- konverziók és típus kasztolások
- bit-műveletek: NOT, AND, OR, XOR, XAND
Használata: simd fordítási direktívával lehetséges Például:
-
egyszerű vektorizáció
pragma simd or (int i = 0; i < n; i++) A[+= B[i](i]);
-
adat párhuzamosítás OpenMP segítségével
pragma omp parallel for simd or (int i = 0; i < n; i++) DoSomeWork(A[i]);
AoS -> SoA
A kiindulás probléma az, hogy a struktúrákat tartalmazó vektort nem lehet jól vektorizálni, mivel a cache-ben tárolt adatok nagy többsége feleslegesen van bent, mivel azon adatokat csak egy későbbi ciklus futás során fogja az alkalmazás feldolgozni. Tehát ezen adatok jelenleg feleslegesen foglalják a cache területet, ahelyett, hogy hasznos adatot tárolnánk ott.
struct MyStructure {
float x, y, z;
}
void My_Function(cons int nItem, MyStructure* const Items, const float delta) {
for (int i = 0; i < nItem; i++) {
...
for (int j = 0; j < nItem; j++) {
const float dx = Items[- Items[i](j].x).x;
const float dy = Items[- Items[i](j].y).y;
const float dz = Items[- Items[i](j].z).z;
...
}
}
...
}
A vektorban a struktúrák tárolása helyett minden elemnek egy dedikált vektort allokálunk és így könnyen tudja a fordító vektorizálni azt. Természetesen segítségként a vektor feldolgozását "tömbösítettük" a tileSize méret megadásával illetve a unroll fordítási direktíva segítségével.
struct MyStructureSet {
float *x, *y, *z;
}
void My_Function(cons int nItem, MyStructure* const Items, const float delta) {
const int tileSize = 16;
#pragma omp parallel for schedule(guided)
for (int ii = 0; ii < nItem; ii+= tileSize) {
...
#pragma unroll(tileSize)
for (int j = 0; j < nItem; j++) {
#pragma unroll(tileSize)
for (int i = ii; i < ii + tileSize; i++) {
const float dx = Items.x[- Items.x[i](j]);
const float dy = Items.y[- Items.y[i](j]);
const float dz = Items.z[- Items.z[i](j]);
...
}
}
}
...
}
Hatékony hossz választás
Olyan esetben jelent előnyt, ha például az n*n-es mátrix esetén n nem osztható 16-val, mert akkor a vektorizáció nem teljesen hajtható végre.
// n%16 != 0
float* A = _mm_malloc(sizeof(float)*n*n, 64);
Ilyen esetben mindig marad egy kis vektor részlet, amire elemenként kell elvégezni a műveletet. A megoldást az jelenti, hogy a memória allokálást kiterjesztjük és nagyobb memória területet foglalunk a változónak, így már alkalmazható lesz a vektorizáció, mivel a maradvány területen is el tudjuk végezni a műveletet egy lépésben.
int lda=n;
if (n % 16 != 0) lda += (16 - n%16); // most lda%16==0
float* A = _mm_malloc(sizeof(float)*n*lda, 64);
// használat
for (int i = 0; i < n; i++)
for (int j = 0; j < n; j++)
A[+ j](i*lda) = ...
"Héj ciklusok" kiküszöbölése
Ciklusok esetén lehetséges, hogy a vektorizációt nem teljes mértékben ismeri fel a fordító program. Ekkor segíthetünk a fordítónak egy fordítási direktívával (#pragma vector aligned), ha teljes mértékben biztosak vagyunk, hogy a ciklusunk vektorizálható!
#pragma vector aligned
for (int j = 0; j < n; j++)
A[+ j](i*lda) -= ...
Ettől jelentős futás idejű javulást érhetünk el, mivel ezzel a #pragma-val kikapcsoltuk a futás idejű ellenőrzést, de előfordulhatnak olyan esetek, főleg amikor nem jól mértük fel a ciklusunkat és nem sikerült a vektorizálás, hogy Segmentation fault hibára fogunk futni.
Regularizáció
Van egy ciklusunk, ami egy vektor elemeit módosítja. A processzor az adatokat "csokorba szedve" emeli be a belső kis méretű cache-be. Egyszerre természetesen több vektor elem is bekerül a a cache-be ezzel gyorsítva a feldolgozást. Ezen vektor iterációk valahogyan ráilleszkedik a vektorra.
Abban az esetben, amikor ez az illesztés nem teljesen tökéletes (lsd. piros elemek), keletkeznem héj ciklusok, melyeket a regularizációval is eliminálni lehet. A feladat eredetileg valahogyan így nézhet ki:
for (int i = 0; i<n; i++)
A[i]=...
Ez a következő átalakítással már alkalmas vektorizációra és nem lesz "peel loop" probléma.
for (int b=0; b<n; b++) {
const int jStart = b- b%16; // mindig osztható 16-val
...
#pragma simd
for (int j = jStart; j<n; j++)
A[j]=...
Párhuzamosítás
Több féle mód létezik a párhuzamosításra. Korábban említettük a SIMD technikát, ami adatpárhuzamosításra való 1 processzoron belül, de létezik még processzorok közti párhuzamosítás, amit az OpenMP segítségével tudunk hatékonyan megvalósítani. Amennyiben gépek közti párhuzamosításra, üzenek küldésre van szükség, akkor az MPI-t kell segítségül hívni. Általános megoldás nem létezik minden feladatra, mert MPI is alkalmas lehet gépen belüli párhuzamosításra, nem csak az OpenMP. Amit mérlegelni kell, hogy mi az amire az alkalmazásnak szükséges van illetve mekkora kommunikációs overhead keletkezik, ha lecseréljük az OpenMP-t MPI-ra. Általában az egymástól független számításokat OpenMP-vel, míg a kommunikációt igénylő feladatokra MPI-t szoktak használni.
Szálak párhuzamosítása
Az OpenMP-nek környezeti változók segítségével megadható a párhuzamosan futtatható szálak száma. Ezt a következő paranccsal tudjuk megtenni, ahol 5-re állítjuk.
export OMP_NUM_THREADS=5
Forrásban a párhuzamos szálakat a #pragma omp parallel segítségével adhatjuk meg.
#pragma omp parallel for //külső for szálak párhuzamosítása
for (int i = 0; i < n; i++)
#pragma simd // vektorizáció a belső cikluson
for (int j = 0; j < m; j++)
My_Function(A[i][j]);
A fordítási direktívák össze is vonhatóak, ilyenkor 1 ciklus is elég.
#pragma omp parallel for simd
for (int i = 0; i < n; i++)
My_Function(A[i]);
Változók láthatósága, megosztása
Változók hatókörét a programozási nyelven kívül pragma-k segítségével is beállíthatjuk, hogy megosztott legyen a változó vagy a szálra nézve saját példány. Amennyiben nem definiáljuk felül, akkor minden változó megosztott. A felül definiálást a private és a shared paraméterekkel lehet megadni az OpenMP-nek.
int A, B, C;
#pragma omp parallel private(A) shared(B)
{...}
Az itteni példában az B és C megosztott változó a szálak között, míg A-t minden szálnak lemásolja a futás kezdetén.
Párhuzamos szálak ütemezése
OpenMp a szálak ütemezésére három féle módod kínál fel. Módok:
- static (alapértelmezett): egyenletesen arányban egymás után elosztja a processzeket az indított szálakon, ezért a futási idő tetszőlegesen elhúzódhat, ha egyes processzek lassabban futnak le.
- dynamic: minden esetben az első szabad szálra kerül a következő processz ütemezése, folyamatos kihasználtságot elérve, de "költséges" a sok-sok ütemezés
- guided: Az előző két mód ötvözése. Nagyobb procesz számot ütemez az éppen szabad szálakra, melyek számát folyamatosan csökkenti a futás előre haladtával, hogy körülbelül egyszerre fejeződjön be minden szál futása, ezzel csökkentve a dynamic esetén magad ütemezési időráfordítást.
Mindhárom esetben megadható az egyszerre ütemezett processzek száma, amit a chunk értéke határoz meg. Ha megvan adva a chunk értéke, akkor az minden esetben annak megfelelő processzámot ütemez a szálakra. Használata:
#pragma omp parallel [schedule (<mode>,<chunk>) {...}
Szálak szinkronizációja
Szála szinkronizálását többféle módon lehet megvalósítani, de ezen megoldások sajno jelentősen lelassítják a program futását.
- mutexxel: nagyon lassú, állandóan várnak egymásra a párhuzamos szálak
#pragma omp parallel for
for (int i = 0; i < n; i++) {
#pragma omp critical
{ // kritikus szekció, csak egy szál hajthatja végre
total = total + i;
}
}
- atomi művelet definiálása: sajnos még ez is lassú, de itt már nem olyan "erős" a szinkronizáció, ezért rendkívül sok limitációja van az itt használható atomi műveleteknek.
#pragma omp parallel for
for (int i = 0; i < n; i++) {
#pragma omp atomic
total += i;
}
Párhuzamos redukció
Az itt bemutatott eljárás gyorsabb mint a fenti szinkronizációs megoldás, de sajnos nem alkalmazható vektorokra! A redukciót a reduction(operation: scalar) formában kell megadni.
int sum = 0;
#pragma omp parallel for reduction(+: sum)
for (int i = 0; i < n; i++) {
sum = sum + i;
}
Tulajdonképpen a fenti problémakörre a következő minta ad megoldást. Ekkor egy külön változóban akkumuláltatjuk a szál általi összeget és ezen értékeke összegyűjtését végezzük csak atomi műveletként.
int sum = 0;
#pragma omp parallel
{
int sum_thr = 0;
#pragma omp for
for (int i=0; i<n; i++)
sum_thr += i;
#pragma omp atomic
sum += sum_thr;
}
Ciklusok párhuzamosítása
Ciklus párhuzamosítására a következő mintát szokás használni.
#pragma omp parallel
{
// Az itt definiált forrást minden szál esetén végre fog hajtani
...
#pragma omp for [schedule (<mode>,<chunk>)
for (int i = 0; i < n; i++) {
// Ez a kódrész lesz párhuzamosítva
...
}
// ... és ez a köd is minden szál esetén végrehajtódik
...
}
Ciklus kifejtés
A technika már egy példa erejéig a vektorizációnál is látható, de ott nem került részletezésre. A megoldás lényege, hogy a kellően nagy ciklust szétdaraboljuk kisebb darabokra, amit már külön feldolgozhatóak, ezzel párhuzamosítva a folyamatokat. Az egy darab kiindulási ciklusból két darab egymásba ágyazott ciklust hozunk létre, ami ugyanazon a feladattéren dolgozik.
Eredeti állapot:
for (int i = 0; i < n; i++) {...}
Átírt változat:
int STRIP=1024;
for (int ii = 0; ii < n; ii += STRIP)
for (int i = ii; i < ii+STRIP; i++) {...}
// ha még van maradék elem, akkor azokon is végrehajtjuk a számításokat
if (n%STRIP != 0) {
for (i=n-(n%STRIP)+1; i<n; i++) {...}
}
A darabok mérete (STRIP értéke) az adott rendszer és feladat függvényében változhat, tehát ez egyfajta "tuning" paraméter.
Automatikus ciklusösszevonás
Az OpenMP támogatást nyújt több egymásba ágyazott ciklus "összevonására". Ehhez csak a collaps fordítási direktívát és az összevonandó ciklusok számát kell megadni. FONTOS: ekkor az automatikus vektorizáció kikapcsolásra kerül!
#pragma omp parallel for collaps(2)
for (int i=0; i<n; i++)
for( int j=0; j<m; j++){...}
A fneti példában a 2db for ciklis kerül párhuzamosításra úgy, hogy a fordítás során 1db ciklus generálódik belőle, ami a következő paraméterezéssel ekvivalens:
#pragma omp parallel for
for (int c=0; c < n*m; c++) {
int i = c/n;
int j = c%n;
...
}
Privacy_Policy
Privacy policy of HPC services
This privacy policy explains how the LEO HPC cluster operational team (hereafter referred to as "we") collects, uses and manages users' data. Before going into details, we stress that we are committed to securing and respecting your privacy, in other words, the protection and security of your data in compliance with all the relevant regulations, as well as cultural, moral, and ethical norms.
Official information
- Name of the data controller: Governmental Agency for IT Development
- Short name: KIFÜ
- Address: Váci út 35, 1134 Budapest, Hungary
- Tax number: 15598316-2-41
- Registration number: 598316
- Statistical number: 15598316 8411 312 01
- Website: https://kifu.gov.hu
- Representative: President Zoltán Szijártó
- E-mail: info@kifu.gov.hu
- Phone number: +36 1 795 2861
- Data protection officer: Dr. Mária Kunhegyi
- E-mail of data protection oficer: adatvedelem@kifu.gov.hu
Legal framework of Data privacy
- Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation), hereinafter referred to as the GDPR
- Act CXII of 2011 on the right to information self-determination and freedom of information law of Hungary
- 5/20011. (II.3) Government Decree on the National Information Infrastructure Development Program
- 268/2010. (XII.3) Government Decree on the : Governmental Agency for IT Development The purpose of this data privacy policy is to ensure that the supercomputer capacity provided by the KIFÜ and the related services are handling the data in accordance with Article 12 (1) of the GDPR.
Legal basis for data management
For the processing of personal data provided by the user is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller as defined Article 6 1 (e) of the GDPR. KIFÜ provides the service on 5/2011. (II.3) on the National Information Infrastructure Development Program to the group of beneficiaries specified in the Government Decree.
To whom the policy applies
The LEO HPC cluster privacy policy, as appropriate and in the relevant sections, applies to all users of the LEO HPC cluster.
How, when we collect your data and what purpose
We collect the following personal data:
- Personal information received during federated authentication:
- eduPersonPrincipalName: a unique identifier in the federation
- mail: the email address used in the Service
- sn: User's last name
- givenName: the first name of the User We use this data to identify you and send possible reports via e-mail
- Personal data processed in connection with a project application: name; e-mail address; institution, department, telephone number. We use this data to contact project submitter after project approval
- Profile data provided by the user on the portal: title, name, affiliation, organization, department, address, phone number, email. We use this data to contact the user in case of problem with the project
- Data management related to error reporting: telephone number, e-mail We use this data to contact the user in case he or she reported a problem.
- Log entries: The log entries generated during the use of the Service (eg. IP addresses, web server logs) KIFÜ retains for 30 days.
Whenever you interact with the LEO HPC cluster, we also automatically receive and record information on our server log files, which may include network addresses you use to connect to the system, device identification, the type of client and/or device you're using to access our system, the time and date you accessed the cluster, and the time spent logged into the service. We may store details of any aspects of the cluster use, including, for example, the amount of processor time and storage space used by user accounts. This may include some personally identifiable data, such as the network addresses or type of device you use to connect to the system. We will use this information to help us manage and administer the cluster, to review, analyze and improve its performance, security, its patterns of use, and to plan for future upgrades.
We reserve the right to monitor the use of the cluster by your account, including anything transmitted over the Internet, and any data or software stored on our systems, in order to ensure that you and all the other users are complying with the Terms of use and Conditions of access and not breaking the law.
Where and how your data is stored
All LEO HPC cluster equipment is hosted on a single site at KIFÜ, and personal information is stored and processed only on this equipment. Also, we have implemented appropriate technical and organizational security measures designed to protect the security of any personal information we collect and process.
We aim to protect your account's privacy and other personal information we hold in our records; however, we cannot guarantee complete security. Unauthorized entry or use, hardware or software failure, and other factors may compromise user information security at any time.
Who do we share your data with?
Collected personal information will be available to the LEO HPC operational team only. Project Resource usage and statistical information might be shared with third parties and reported in publicly available documents.
How long does the cluster keeps your data?
After the end of your use of the LEO HPC cluster, we have no need to process your personal information, and it will be deleted, or, if this is not possible (for example, because your personal information has been stored in backup archives), we will securely store your personal information and isolate it from any further processing until deletion is possible. However, data that could be used to identify you directly will not be retained for longer than five years.
Your rights
As a person whose data we hold, in general, your rights are outlined by Europe's General Data Protection Regulation (GDPR) whether you are resident of European Economic Area (EEA) or not, and in certain circumstances includes:
Right of access
You have the right to submit a request to the LEO HPC operational team to obtain information on whether we are processing your data. In the case that your data is processed, you may request at any time a copy of the personal data we hold about you.
Right to correction
All data that we process is reviewed and verified as accurate, whenever possible, and updated regularly. If you believe that the data is incorrect or has changed, you have the right to request that we correct those data.
Right to be forgotten or right to erasure
You have the right to request from the LEO HPC operational team to delete your data unless there is a legal obligation to keep that data or there is a legal basis for refusing a request for deletion of data.
Right to restriction of processing
You have the right to obtain from the controller restriction of processing where one of the GDPR Article 18 (https://gdpr-info.eu/art-18-gdpr/) conditions is met.
Right to data portability
You have the right to request the transfer of data to another operator if the processing is based on your consent or by automated means. We make sure that all personal information is readily available and is in a structured, commonly used, and machine-readable format.
Right to object
You have the right to object to the way we handle your data if the processing of the data is based on the Scientific Computing Laboratory's legitimate interest, or in carrying out a task in the public interest/for an official authority. Besides, you may object to the processing of your data for direct marketing purposes, which includes profiling to the extent that it is related to such direct marketing, as well as scientific/historical research and statistics.
Right to withdraw the consent
If the data processing is based on your consent, you may withdraw the consent at any time.
Please note that we will ask you to verify your identity through several forms before responding to such requests. Requests will be addressed as soon as possible.
Contact information
If you have any questions about this privacy policy, please contact us by e-mail: adatvedelem@kifu.gov.hu
Changes to the privacy policy We regularly revise and update personal data processing information following changes in internal operational procedures or based on obligations arising from relevant regulations. Therefore, we reserve the right to modify and update the present policy whenever deemed necessary, whereas any changes shall become effective after publication on this Privacy Policy
HPC-Portal
A portál célja
- A HPC portál célja a szuperszámítógépek és felhasználóik egységes, és kényelmes adminisztrációja, a kommunikáció egyszerűsítése.
- A honlapon az éppen futó kutatási projektekről lehet tájékozódni, mint például a felhasznált processzor idő (felhasználói és aggregált), havi kvóta (szuperszámítógépekre bontva), munkacsoport felhasználóinak aktivitása stb. Az adatokat megtekinthetőek dinamikusan kezelhető diagramokon, általános információk jeleníthetőek meg a szolgáltatások aktuális állapotáról illetve a várható eseményekről, valamint megújított hibabejelentő rendszer is igénybevehető.
- Projektvezetőknek továbbfejlesztett adminisztrációt és leegyszerűsített munkamenetet nyújt az új kvótaigénylési rendszer, melynek során az igénylések gyorsabban kerülnek elbírálásra, így a lehető leghamarabb állhat rendelkezésre az igényelt processzoridő, valamint egyszerűen és áttekinthető módon nyerhet információt a projekten dolgozó munkatársak által felhasznált erőforrások alakulásáról.
Hozzáférés igénylése
Bejelentkezés eduID-vel
- A HPC portálhoz a KIFÜ által elfogadott HPC projektek projektvezetői, és felhasználói férhetnek hozzá. A bejelentkezéshez eduID tagsággal kell rendelkezni. Az eduID-ról bővebben ezen az oldalon olvashat.
Virtuális befogadóintézmény (VHO) tagság igénylése
Projekt igénylés
- A szuperszámítógépes infrastruktúra felhasználása projektek keretében történhet, azaz a KIFÜ projektnek tekinti az összes olyan kutatási/tudományos tevékenységet, melynek támogatására szuperszámítógép témaszámot kérnek. Új projekt igénylése esetén ki kell tölteni az alábbi honlapon található kérdőívet, melyet postai vagy személyes úton kell a KIFÜ címére eljuttatni.
A portál bemutatása
A portál itt érhető el:
Személyes adatok menü
Személyes adatok
- Ebben a menüpontban a felhasználó a saját adatait tudja szerkeszteni. Kitöltése nem szükségszerű, de javasolt. A név és e-mail cím automatikusan kitöltésre kerül az eduID-val történő első bejelentkezés álltal, ez tetszőlegesen módosítható, de célszerű olyan e-mailcímet megválasztani, melyet rendszeresen olvas, mivel ez a portál elsődleges kommunikációs csatornája.
SSH kulcs
- Az open-ssh formátumú ssh publikus kulcsot kell ebbe a mezőbe beilleszteni, majd a zöld nyílra nyomva menteni a változtatást. A feltöltött ssh kulcs rendszerben történő élesítése akár egy napot is igénybe vehet, ezért érdemes ezt az első belépés során elvégezni. A feltöltött ssh kulcs a szupergépekre történő belépéskori azonosításhoz szükséges. A feltöltött ssh kulcsot a lefele mutató kék nyílra kattintva tudja letölteni. SSH kulcspár generálásáról bővebben az alábbi oldalon olvashat.
X.509 tanúsítványok
- Minden projekt, melyben felhasználónk részt vesz, tartozik egy X.509 tanusítvány is, melyeket a rendszer automatikusan generál nekünk. Az egyes projektekhez tartozó tanúsítványok listáját jeleníti meg az ablakban. Új tanúsítvány generálásához a sor végi zöld nyílra kell kattintani. Az elkészült tanúsítvány az alábbi ablak jelenik meg, ahol általános információk megjelenítésén túl le tudja tölteni a tanúsítványt illetve a hozzá tartozó titkos kulcsot, valamint megjelnítésre kerül a kulcshoz tartozó jelszó is. Ezeket érdemes megjegyezni, vagy az alábbi parancs futtatásával a kulcshoz tartozó jelszót módosítani:
openssl rsa -in userkey.pem -out userkey.pem -des3
. Adott projekthez tartozó X.509 tanúsítvány 14 napon belül lejár, ebben az esetben a tanúsítvány újragenera kell generálni és ismét használható lesz. Tanúsítvány törlésére a szemetes ikon megnyomásával van lehetőség. Ha nem szeretnénk minden második héten új X.509-es tanúsítványt igényelni, akkor lehetőség van arra is, hogy 1 évig érvényes IGTF tanúsítványt igényeljünk a KIFÜ-től ezen az oldal keresztül. Ebben az esetben a [mailto:hpc-support@niif.hu] címre kell elküldenünk az IGTF-es tanúsítványunk publikus részét és meg kell adnunk, hogy melyik témaszámunkhoz legyen majd rendelve a szuperszámítógépeken.
Felhasználási lehetőségek a szuperszámítógépek esetén: GSI-SSH, GridFTP, ARC köztesréteg
Hírek
- Ebben a menüpontban jelennek meg a szupergépekkel és hozzájuk fűződő eseményekkel kapcsolatos cikkek, írások, karbantartási események.
Projekt
- Ezen az oldalon általános tájékozódáshoz juthat az éppen futó projektjeivel kapcsolatban, projektvezetőként engedélyezhet felhasználókat, meghívhat újakat, valamint igényelhet CPU időt az adott hónapra. Projektek között az ablak felső sávjában elhelyezkedő gombok segítségével tud váltani.
Projekt információk
- Általános projekt információk kerülnek ezen a felületen megjelenítésre, mint például a projekt neve, az adminisztrátor(ok), felhasznált CPU idő kvóta, általános leírás a projektről, valamint a szupergépenkénti kvótafelhasználtság havi állapota. Amennyiben a bejelentkezett felhasználó az éppen megjelenített projekt adminisztrátora, akkor ezen a felületen lehet CPU időt igényelni valamint lezárni a projektet.
Projekt felhasználók
- Ebben az ablakban látható a projekthez tartozó felhasználók listája. A táblázatban helyet kapott a felhasználókhoz tartozó unix azonosító, az aktuális hónapban általuk elhasznált CPU idő, valamint a jelenlegi státuszuk. Az admin felületen a státusz mezőben egy piros x jel (illetve egy zöld pipa) segítségével lehet a felhasználót aktívból passzív (és fordítva) státuszba állítani. Új felhasználó meghívására pedig a táblázat alatti gomb segítségével van lehetőség.
Projekt statisztikák
- Grafikonon jeleníthetjük meg az elmúlt időszak (hónap vagy év) CPU idő fogyasztási adatait. Az aggregált statisztikán látható az egyes szupergépeken felhasznált CPU idő mennyisége, a normál statisztikát választva pedig szupergépenként láthatjuk egy-egy grafikonon, hogy a projekt felhasználói mennyi erőforrást használtak fel adott időszakban.
Szolgáltatások állapota
HPC szolgáltatások állapota
- Az oldal betöltését követően a portál lekérdezi a szupergépek egyes rész- és alrendszereinek állapotát, majd táblázatos formában nyújt róla információt a felhasználó számára.
Események
- Azok a tervezett események kerülnek ebbe az időtáblába, melyek a hírek oldalon is megjelennek szöveges formában (a megfelelő mezőre kattintva elérhető az esemény szöveges oldala). A navigációs gombok használatával közelíthetünk, távolíthatunk, illetve haladhatunk az időben előre és hátra is. A navigációs funkciók elérhetőek az egér bal gomb lenyomva tartásával és közben az egér oldalirányú mozgatásával valamint a közelítés/távolítás görgetéssel.
Események szűrése
- Ez az ablak szolgál a megjelenített események szűkítésére, kiválasztható, hogy melyik szupergépen történt események, milyen időintervallumban jelenjenek meg.
Hibabejelentés
- Ezen az oldalon lehet nyomon követni a beküldött hibajegyeket. Ezeknek a beküldési dátumait, státuszait és egyéb, általános információit a hibajegy lista ablakban lehet látni.
Hibajegy nyitása
- Hibajegy nyitása gombra kattintva egy hibajegy beküldő oldalra navigál minket a portál. A hibabejelentő űrlapon kiválasztható, hogy melyik projekttel kapcsolatban fordult elő a hiba, valamint a másik legördülő menüből választható pár tipikus hiba, melynek segítségével az űrlap pár kérdésen keresztül pontosítja a hiba jellegét, hogy a lehető leggyorsabban tudjon technikai személyzetünk megoldást találni a problémára. Nagyon fontos, hogy megadja az űrlap alján elérhetőségét, hogy amennyiben a hiba feltárása során kérdések merülnének fel, ezeket önnek egyeztetni tudjuk.
Korábbi projektek migrációja
- Minden témavezető részére kiküldésre kerül egy tájékoztató e-mail. A levélben található link eléréséhez eduID belépés szükséges. A belépést követően a témavezető alá tartozó projektek migrációja automatikusan zajlik le a háttérben.
- A témaszámmal rendelkező felhasználók ezt követően kapnak e-mailt a migrációval kapcsolatban. A levél szintén tartalmaz egy személyre szabott linket, melyre kattintva az eduID bejelentkezést követően megtörténik a felhasználó migrációja is.
- Kérjük, hogy a migrációt követően ellenőrizzék e-mail címüket a Saját adatok menüpont alatt!
- A projektek migrációját a portál indulását követő első fél évben el kell végezni, ezután meglévő projektek migrációjára már nem lesz lehetőség. Új projekt ezután már csak kizárólag a HPC portál igénybevételével igényelhet témaszámot.
Grid Portál
- Ez egy olyan webes felület a szupergépeket használó kutatók számára, amin keresztül egyszerűsített módon tudják a számítási feladataikat kezelni. A portál lehetőséget nyújt feladatok beküldésére, azok állapotának nyomon követésére, majd az eredmények letöltésére. A portál felgyorsított munkamenetet, átlátható információkat és mindenek felett kényelmet biztosít felhasználói számára. A portálra történő bejelentkezéshez eduID tagság szükséges.
- További információt a Grid Portál használatáról az alábbi linken kaphat.
Egyéb információk
Adatkezelési szabályzat
Adatkezelő neve és elérhetősége
- Név: Kormányzati Informatikai Fejlesztési Ügynökség (KIFÜ)
- Cím: 1132 Budapest, Victor Hugo utca 18-22.
- Telefon: +36 1 450-3060
- Fax: +36 1 350-6750
- Az adatkezeléssel kapcsolatos kérdéseivel a fenti telefonszámon, ill. az
aai kukac niif.hu
e-mail címen kaphat további információkat.
Szolgáltatás megnevezése
- A KIFÜ által üzemeltetett szuperszámítógépekhez tartozó projektek és felhasználók adatainak az adminisztrációját ezen az oldalon lehet elvégezni.
Az adatkezelés célja
- Az Adatkezelő jelen szabályzat által meghatározott adatkezelése a felhasználónak nyújtott Szolgáltatás működtetése érdekében történik. Az Adatkezelő csak az adatkezelés céljának megvalósulásához elengedhetetlen, a cél elérésére alkalmas személyes adatok megadását kéri, továbbá csak a célok megvalósulásához szükséges mértékben és ideig kezeli e személyes adatokat. Az Adatkezelő a jelen Szabályzatban megjelölt céloktól eltérő célra a személyes adatokat nem használja.
Az adatkezelés jogalapja
- Az adatkezelés az Avtv. 3. § (1) bekezdése alapján a felhasználó önkéntes, tájékozott és határozott hozzájárulásán alapul.
Kezelt személyes adatok köre
Föderációs azonosítás során megkapott személyes adatok
- eduPersonPrincipalName: egyedi azonosító a föderációban
- mail: a Szolgáltatásban használt e-mail cím
- sn: a Felhasználó vezetékneve
- givenName: a Felhasználó keresztneve
A Szolgáltatás használata során keletkező személyes adatok
- A Szolgáltatás használata során az alábbi adatok tartalmazhatnak személyes adatokat: Projekt tagság
- Kizárólag Felhasználó felelős a fenti bejegyzések tartalmáért. Ezen bejegyzéseket Adatkezelő a Szolgáltatás használata után is megőrzi, az után is, hogy a felhasználó az adatainak eltávolítását kérte a rendszerből, mivel ez szükséges ahhoz, hogy a Szolgáltatás a céljának megfelelően működhessen.
Felhasználó által megadott adatok
- Felhasználó a Szolgáltatás használatával további személyes adatokat is megadhat a profiljában. A profil oldalán beállított adatokat a többi bejelentkezett felhasználó is láthatja. A profil adatokat Adatkezelő kérésre törli a rendszerből.
Naplóbejegyzések
- A Szolgáltatás használata során keletkezett naplóbejegyzéseket (pl. IP címek, webszerver naplók) Adatkezelő 30 napig őrzi meg.
Adatok kiadása harmadik fél számára
- Adatkezelő a nála keletkezett személyes adatokat nem adja ki harmadik fél számára, kivéve, ha ez a Szolgáltatás üzemszerű működéséből következik.
Adatbiztonság
- Az Adatkezelő az érintett személyes adatai kezelésének műszaki biztonságát biztosítja, valamint műszaki és szervezései intézkedésekkel meggátolja azt, hogy a személyes adatokhoz illetéktelen személyek hozzáférhessenek.
SSH_kulcs_generálás
A szuperszámítógépekre történő belépés kizárólag az SSH nyilvános kulcsú titkosításon alapuló kulcsos authentikáció segítségével lehetséges. Az azonosítás eszköze egy kulcs pár, amely titkos fele kizárólag a felhasználó birtokában lehet, ezzel zárva ki egy esetleges rossz indulatú megszemélyesítésen alapuló támadást. A kulcs nyilvános fele szabadon terjeszthető, továbbá a témaszám regisztráció során is kötelezően elküldésre kerül.
Mivel a kulcs titkos felének biztonsága kritikus szempont, annak generálása kizárólag a felhasználó számítógépén mehet végbe. A következő leírásunkkal ehhez szeretnénk segítséget nyújtani. Mivel a generáláshoz szükséges lépesek operációs rendszerenként eltérőek lehetnek, külön fejezet foglalkozik a Unix-szerű és a Windows operációs rendszerekkel. A leírásokban említett alkalmazások számos esetben sokkal több kapcsolóval és beállítási lehetőséggel rendelkeznek, mint amelyek itt bemutatásra kerülnek, mi csak a legszükségesebbek bemutatására szorítkozunk. További lehetőségek megismerhetők az egyes alkalmazások hivatalos dokumentációinak segítségével.
Unix-szerű operációs rendszerek (Linux/OS X/stb.)
A generáláshoz az OpenSSH programcsomaghoz tartozó ssh-keygen alkalmazást tudja használni. A saját számítógépén futtassa le a következő parancsot:
% ssh-keygen -t rsa -b 4096
A parancs futása során megadható a titkos kulcs helye, amely megadása nélkül a fájlok az alapértelmezett helyükre kerülnek. (Ennek használata, ha nem áll fenn kizáró tényező, erősen ajánlott.) A következő lépésben jelszó/jelmondat is megadható biztosítandó a titkos kulcs biztonsága. (Amennyiben ezt a sort üresen hagyja, úgy nem kerül ilyen védelem a titkos kulcsára.) Végül a program futtatásának hatására elkészül mind az Ön nyilvános, mind a titkos kulcsa. Ezeket, amennyiben a generálás során az alapértelmezett értékeket nem változtatta meg, megtalálja sorra az alábbi helyeken (ahol az útvonalakban szereplő $HOME változó az Ön home directory-jére hivatkozik):
$HOME/.ssh/id_rsa.pub
$HOME/.ssh/id_rsa
A regisztráció során a $HOME/.ssh/id_rsa.pub fájl tartalmára lesz szükség. A publikus kulcs a következőhöz hasonló formátumú:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDHsxSQuT8q5uSS8PhtlylPWkoEvP
2KGAwhai/mBcs6xCYmMv0/tW9z6UmK7+zVqUNIUXgTOoTVtFwL6JJxSY3phNgUQfAtkjebJ
0qVLR0xcaMysSzhMptdyRST4g/E75FyePPiCj38Z2QUv4zGEABWHe/emwD566YhIEjHrST6
flRohsDWJU4lgkargrfI4mcv5pUgxbXIWyaCIJqAFAnxcGRhUCfCBmCKXhJw1XOL9uEA1Fv
c2Te13gUUHgSBv/9M8eaKwAsOdykd6fGAXSwA0tqqG6iJfJ1LxhGpUKNCFzOjHdN3hBGkW1
VxxhvLMF0fS8/Dr7Xy+Zm84smtvJWJS4ghlLRAnCsGcEVwhPaBwHCR5r2YCajKbgLt/ibmU
hkq3ULgwq6pZWm9OTbQ2uBad/Ao5Hc+BQ8G+8C0a73HvBcy1Ta4zeU13FMcaA3veskPeqHm
CQodmMkyhM0XnaWlF/xzPxnzuEFfFxe3lkenio7AnrA0WTU9Cq3mpLFgZS8kAUerjW42qoZ
yMI3ewJeqi1Llqi7UysXG6N5785kQ3xo3RNjz6FiNO5W1iNqDraTh+mIfYqWYpf744HIXib
GsWyhLEOgoJyDmMXpl11uN0fk+0oWkKrtkfMYv9J9U9aMpzdgFDPbw/qCgYmL+XZJBZAoUs
8Vb8PL2DqWDFC+/Aw== user@host
Windows operációs rendszer
Windows operációs rendszeren a PuTTY programcsomagban található PuTTYgen alkalmazás segítségével készíthetők el a szükséges kulcsok. A kulcsgenerálással a szoftver kézikönyvének 8. fejezete, a nyilvános kulcs kiolvasásával pedig ezen belül a 8.2.10-es fejezete foglalkozik. A generáláshoz szükséges lépesek a következők:
- Töltse le és indítsa el a PuTTYgen alkalmazást!
- A “Paraméterek” mezőben válassza ki a “SSH-2 RSA” pontot a kulcs típusánál, valamint állítsa át 4096 bit-re a generálandó kulcs bitjeinek a számát, majd kattintson a ”Generate” gombra!
- Mozgassa az egerét a kis mezőben a szükséges kulcs párok elkészítéséhez!
- Itt adhat meg továbbá megjegyzést és jelszót/jelmondatot a készülő kulcshoz.
- Kattintson a “Save private key” majd a “Save public key” gombokra rendre a titkos, illetve a nyilvános kulcs lementéséhez!
A regisztráció során Önnek a publikus kulcsát kell megadni az űrlapon. A publikus kulcs a következőhöz hasonló formátumú:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDHsxSQuT8q5uSS8PhtlylPWkoEvP
2KGAwhai/mBcs6xCYmMv0/tW9z6UmK7+zVqUNIUXgTOoTVtFwL6JJxSY3phNgUQfAtkjebJ
0qVLR0xcaMysSzhMptdyRST4g/E75FyePPiCj38Z2QUv4zGEABWHe/emwD566YhIEjHrST6
flRohsDWJU4lgkargrfI4mcv5pUgxbXIWyaCIJqAFAnxcGRhUCfCBmCKXhJw1XOL9uEA1Fv
c2Te13gUUHgSBv/9M8eaKwAsOdykd6fGAXSwA0tqqG6iJfJ1LxhGpUKNCFzOjHdN3hBGkW1
VxxhvLMF0fS8/Dr7Xy+Zm84smtvJWJS4ghlLRAnCsGcEVwhPaBwHCR5r2YCajKbgLt/ibmU
hkq3ULgwq6pZWm9OTbQ2uBad/Ao5Hc+BQ8G+8C0a73HvBcy1Ta4zeU13FMcaA3veskPeqHm
CQodmMkyhM0XnaWlF/xzPxnzuEFfFxe3lkenio7AnrA0WTU9Cq3mpLFgZS8kAUerjW42qoZ
yMI3ewJeqi1Llqi7UysXG6N5785kQ3xo3RNjz6FiNO5W1iNqDraTh+mIfYqWYpf744HIXib
GsWyhLEOgoJyDmMXpl11uN0fk+0oWkKrtkfMYv9J9U9aMpzdgFDPbw/qCgYmL+XZJBZAoUs
8Vb8PL2DqWDFC+/Aw== user@host
További hivatkozások: https://help.ubuntu.com/community/SSH/OpenSSH/Keys http://kb.siteground.com/article/How_to_generate_an_SSH_key_on_Windows_using_PuTTY.html
PRACE_User_Support
User Guide to obtain a digital certificate
This document gives a short overview about how to require a digital certificate from NIIF CA for users, if the pre-registration form has been filled.
This guide is valid only for the Hungarian users.
If you are from a foreign country, and would like to get a certificate, here you can found your country's certification authority.
Installing NIIF CA root certificate
The first step is to download the "root certificate" ("NIIF CA Root Certificate" part), in the the format, which is known for the used browser or other SSL-using program. The browser asks wether to install/accept the certificate or not - accept or install the certificate in any cases. In addition, activate or allow the option which permits the browser to use the certificate to authenticate websites. Without that, it is not possible to reach the CA's web interface with secure protocol (https). The downloaded/installed certificate can be found in the certificate management modul of the browser.
Request a certificate
Request a certificate with openssl
-
Sing in into the certification registration website of the NIIF CA with our email address and password stored in the directory.
-
This site uses secure protocol (https), which the browser often indicates with a warning window - they should be acknowledged implicitly.
-
In the opening page - which is the public web surface of the CMS certificate management software - choose the "OpenSSL kliens kérelem benyújtása (PKCS#10)" (request an OpenSSL client) option. This leads to the datasheet, which must be filled in accordance with the printed datasheet. First, according to the purpose of the request, the corresponding field must be choosen (CSIRT, GRID, NIIF felhasználó, Független kutató, HBONE).
-
Copy the public part of our certificate in the field "PKCS#10". You can find a user guide about How to create a PKCS#10 certificate with openssl, which suitable for the NIIF CA requirements below.
-
A Challenge and a Request passwords must be given - both of them must be at least 8 characters long. Note them, because they needed for cancellation the certificate, or for the personal authentication.
-
Fill the other fields (name, email address, phone, organisation), and if there is anything, the CA operator should know, fill the last field with it. If everything is done, after a last check, click on the Elküld ("send") button on the bottom of the page.
-
In case of a successful PKCS#10 key-uploading, a page is opening with the confirmation of the successful certification request.
User Guide to create a PKCS#10 digital certification request with openssl
This paragraph gives a short overview about how to require a digital certificate from NIIF CA for users using openssl with the PKCS#10 format.The latest version of the openssl program can be downloaded from: Windows, Linux.
-
Download the openssl configuration file To generate the CSR, there is a prewritten niif_ca_user_openssl.cnf file on the NIIF CA website. The following modifications must be done in the config:
#purpose of the certificate
1.organizationalUnitName = Organizational Unit Name 1.organizationalUnitName_default = GRID # For example: GRID, HBONE, General Purpose 2.organizationalUnitName = Second Organizational Unit Name 2.organizationalUnitName_default = NIIF # For example: BME, ELTE, SZFKI, SZTAKI, NIIF, ... commonName = Common Name (YOUR name) # User Name. commonName_max = 64A -
Create PKCS#10 reqquest a) No existing secret key:
Run the
openssl req -newkey rsa:1024 -config ./niif_ca_user_openssl.cnf -out new_csr.pem
command, and answer the appearing questions at the prompt. The Institute (NIIF CA) and country (HU) datas should not be changed, or the request is going to be invalid. The certification request and the corresponding private key will be saved in the new_csr.pem and privkey.pem files. To gain acces to the private key, during the generating given "pass phrase" password must be used. In case of a forgotten password, the certificate will be unusable.b) Existing private key (extend)
If there is an existing, previously generated private key (it must be at least a 1024 bit RSA key), which can be found in the old_key.pem file, then the following command creates the CSR:
openssl req -new -key ./old_key.pem -config ./niif_ca_user_openssl.cnf -out new_csr.pem
Personal Authentication
After the successful registration on the website, please visit the NIIF CA Registration Office personally with the copy of the pre-registration datasheet, the Request password and an ID document (ID card, passport).
Address:
NIIF Iroda (RA Administrator) Victor Hugo Str. 18-22. H-1132 Budapest, HUNGARY email: ca (at) niif (dot) hu
RA opening hours: Monday, 14:00 - 16:30 (CET)
During the authentication, the colleagues of the Registration Office verify the datas of the certificate and the user, and after the successful identification, they take the next steps in order to create the certification (it is not needed to wait for it).
Downloading the certificate
An email is going to arrive after the valid certificate has been completed (to the given email address during the request), and clicking on the URL in the email, the certificate can be downloaded. The saved certificate does not contain the private key.
If the certificate is installed into the browser, it is advised to export it with the private key in PKCS#12 format, so there will be a common backup with the private key and the certificate. Handle this backup carefully! If the private key lost, or gets into unauthorized hands, immediately request a certificate cancellation at the registration interface "Tanúsítvány visszavonása" (certificate cancellation) or at the Registration Office, and inform the concerned people!
Access with GSI-SSH
A user can access to the supercomputers by using the GSI-SSH protocol.
It requires a machine with a Globus installation that provides the gsissh client.
The needed credentials (these mean the private and public keys) must be created before entering the machine with the
grid-proxy-init
or
arcproxy
commands.
By default, the proxies are valid for 12 hours. It is possible to modify this default value with the following commands:
arcproxy -c validityPeriod=86400
or
grid-proxy-init -hours 24
Both of the previous commands set the validation of the proxies to 24 hours. Using the arcproxy, the validation time must be given in seconds.
To enter the site, the
gsissh -p 2222 prace-login.sc.niif.hu
command has to be used.
GridFTP file transfer
In order to use GridFTP for file transfer, one needs a GridFTP client program that provides the interface between the user and a remote GridFTP server. There are several clients available for GridFTP, one of which is globus-url-copy, a command line tool which can transfer files using the GridFTP protocol as well as other protocols such as http and ftp. globus-url-copy is distributed with the Globus Toolkit and usually available on machines that have the Globus Toolkit installed.
Syntax
globus-url-copy [options] sourceURL destinationURL
-
[options] The optional command line switches as described later.
-
sourceURL The URL of the file(s) to be copied. If it is a directory, it must end with a slash (/), and all files within that directory will be copied.
-
destURL The URL to which to copy the file(s). To copy several files to one destination URL, destURL must be a directory and be terminated with a slash (/).
Globus-url-copy supports multiple protocols, so the format of the source and destination URLs can be either
file://path
when you refer to a local file or directory or
protocol://host[:port]/path
when you refer to a remote file or directory.
globus-url-copy is supporting other protocols such as http, https, ftp and gsiftp as well.
- Example:
globus-url-copy file://task/myfile.c gsiftp://prace-login.sc.niif.hu/home/prace/pr1hrocz/myfile.c
This command uploads the myfile.c file from the locak task folder to the remote machine's home/task folder.
Command line options for globus-url-copy [options]
- -help Prints usage information for the globus-url-copy program.
- -version Prints the version of the globus-url-copy program.
- -vb During the transfer, displays: (1) number of bytes transferred (2) performance since the last update (every 5 seconds) (3) average performance for the whole transfer
The following table lists parameters which you can set to optimize the performance of your data transfer:
-tcp-bs <size>
Specifies the size (in bytes) of the TCP buffer to be used by the underlying GridFTP data channels.-p <number of parallel streams>
Specifies the number of parallel streams to be used in the GridFTP transfer.-stripe
Use this parameter to initiate a “striped” GridFTP transfer that uses more than one node at the source and destination. As multiple nodes contribute to the transfer, each using its own network interface, a larger amount of the network bandwidth can be consumed than with a single system. Thus, at least for “big” (> 100 MB) files, striping can considerably improve performance.
Usage of the SLURM scheduler
Website: http://slurm.schedmd.com
The schedule of the HPCs are CPU hour based. This means that the available core hours are divided between users on a monthly basis. All UNIX users are connected to one or more account. This scheduler account is connected to an HPC project and a UNIX group. HPC jobs can only be sent by using one of the accounts. The core hours are calculated by the multiplication of wall time (time spent running the job) and the CPU cores requested. For example reserving 2 nodes (48 cpu cores) at the NIIFI SC for 30 minutes gives 48 * 30 = 1440 core minutes = 24 core hours. Core hours are measured between the start and and the end of the jobs.
It is very important to be sure the application maximally uses the allocated resources. An empty or non-optimal job will consume allocated core time very fast. If the account run out of the allocated time, no new jobs can be submitted until the beginning of the next accounting period. Account limits are regenerated the beginning of each month.
Information about an account can be listed with the following command:
sbalance
Example
After executing the command, the following table shows up for Bob. The user can access, and run jobs by using two different accounts (foobar, barfoo). He can see his name marked with * in the table. He shares both accounts with alice (Account column). The consumed core hours for the users are displayed in the second row (Usage), and the consumption for the jobs ran as the account is displayed in the 4th row. The last two row defines the allocated maximum time (Account limit), and the time available for the machine (Available).
Scheduler Account Balance
---------- ----------- + ---------------- ----------- + ------------- -----------
User Usage | Account Usage | Account Limit Available (CPU hrs)
---------- ----------- + ---------------- ----------- + ------------- -----------
alice 0 | foobar 0 | 0 0
bob * 0 | foobar 0 | 0 0
bob * 7 | barfoo 7 | 1,000 993
alice 0 | barfoo 7 | 1,000 993
Estimating core time
Before production runs, it is advised to have a core time estimate. The following command can be used for getting estimate:
sestimate -N NODES -t WALLTIME
where NODES
are the number of nodes to be reserved, WALLTIME
is the maximal time spent running the job.
It is important to provide the core time to be reserved most precisely, because the scheduler queue the jobs based on this value. Generally, a job with shorter core time will be run sooner. It is advised to check the time used to run the job after completion with sacct
command.
Example
Alice want to reserve 2 days 10 hours and 2 nodes, she checks, if she have enough time on her account.
sestimate -N 2 -t 2-10:00:00
Estimated CPU hours: 2784
Unfortunately, she couldn't afford to run this job.
Status information
Jobs in the queue can be listed with squeue
command, the status of the cluster can be retrieved with the sinfo
command. All jobs sent will get a JOBID. The properties of a job can be retrieved by using this id. Status of a running or waiting job:
scontrol show job JOBID
All jobs will be inserted into an accounting database. The properties of the completed jobs can be retrieved from this database. Detailed statistics can be viewed by using this command:
sacct -l -j JOBID
Memory used can be retrieved by using
smemory JOBID
Disk usage can be retrieved by this command:
sdisk JOBID
Example
There are 3 jobs in the queue. The first is an array job which is waiting for resources (PENDING). The second is an MPI job running on 4 nodes for 25 minutes now. The third is an OMP run running on one node, just started. The NAME of the jobs can be freely given, it is advised to use short, informative names.
squeue -l
Wed Oct 16 08:30:07 2013
JOBID PARTITION NAME USER STATE TIME TIMELIMIT NODES NODELIST(REASON)
591_[1-96] normal array alice PENDING 0:00 30:00 1 (None)
589 normal mpi bob RUNNING 25:55 2:00:00 4 cn[05-08]
590 normal omp alice RUNNING 0:25 1:00:00 1 cn09
This two-node batch job had a typical load of 10GB virtual, and 6.5GB RSS memory per node.
smemory 430
MaxVMSize MaxVMSizeNode AveVMSize MaxRSS MaxRSSNode AveRSS
---------- -------------- ---------- ---------- ---------- ----------
10271792K cn06 10271792K 6544524K cn06 6544524K
10085152K cn07 10085152K 6538492K cn07 6534876K
Checking jobs
It is important to be sure the application fully uses the core time reserved. A running application can be monitored with the following command:
sjobcheck JOBID
Example
This job runs on 4 nodes. The LOAD group provides information about the general load of the machine, this is more or less equal to the number of cores. The CPU group gives you information about the exact usage. Ideally, values of the User
column are over 90. If the value is below that, there is a problem with the application, or it is not optimal, and the run should be ended. This example job fully using ("maxing out") the available resources.
Hostname LOAD CPU Gexec
CPUs (Procs/Total) [ 1, 5, 15min]() [ User, Nice, System, Idle, Wio]()
cn08 24 ( 25/ 529) [24.83, 24.84, 20.98]() [ 99.8, 0.0, 0.2, 0.0, 0.0]() OFF
cn07 24 ( 25/ 529) [24.93, 24.88, 20.98]() [ 99.8, 0.0, 0.2, 0.0, 0.0]() OFF
cn06 24 ( 25/ 529) [25.00, 24.90, 20.97]() [ 99.9, 0.0, 0.1, 0.0, 0.0]() OFF
cn05 24 ( 25/ 544) [25.11, 24.96, 20.97]() [ 99.8, 0.0, 0.2, 0.0, 0.0]() OFF
Checking licenses
The used and available licenses can be retrieved with this command:
slicenses
Checking downtime
In downtime periods, the scheduler doesn't start new jobs, but jobs can be sent. The periods can be retrieved by using the following command:
sreservations
Running jobs
Running applications in the HPC can be done in batch mode. This means all runs must have a job script containing the resources and commands needed. The parameters of the scheduler (resource definitions) can be given with the #SBATCH
directive. Comparison of the schedulers, and the directives available at slurm are available at this table.
Obligatory parameters
The following parameters are obligatory to provide:
#!/bin/bash
#SBATCH -A ACCOUNT
#SBATCH --job-name=NAME
#SBATCH --time=TIME
where ACCOUNT
is the name of the account to use (available accounts can be retrieved with the sbalance
command), NAME
is the short name of the job, TIME
is the maximum walltime using DD-HH:MM:SS
syntax.
Acceptable time formats include "minutes", "minutes:seconds", "hours:minutes:seconds", "days-hours", "days-hours:minutes" and "days-hours:minutes:seconds".
The following command submit jobs:
sbatch jobscript.sh
If the submission was successful, the following is outputted:
Submitted batch job JOBID
where JOBID
is the unique id of the job
The following commmand cancels the job:
scancel JOBID
Job queues
There are two separate queue (partition) available in the HPC, the test
queue and the prod
queue. Tha latter is for the production runs, the former is for testing purposes. In the test queue, 1 node can be allocated for the maximum of half hours, The default queue is prod
. Test partition can be chosen with the following directive:
#SBATCH --partition=test
Quality of Service (QoS)
There is an option for submitting low priority jobs. These jobs can be interrupted by any normal priority job at any time, but only the half of the time is billed to the account. Interrupted jobs will be automatically queued again. Therefore it is important to only run jobs that can be interrupted at any time, periodically saves their states (checkpoint) and can restart quickly.
The default QoS is normal
, non-interruptable.
The following directive choses low priority:
#SBATCH --qos=lowpri
Memory settings
1000 MB memory is allocated for 1 CPU core by default, more can be allocated with the following directive:
#SBATCH --mem-per-cpu=MEMORY
where MEMORY
is given in MB. The maximum memory/core at NIIFI SC is 2600 MB.
Email notification
Sending mail when the status of the job change (start, stop, error):
#SBATCH --mail-type=ALL
#SBATCH --mail-user=EMAIL
where EMAIL
is the e-mail to notify.
Array jobs
Array jobs are needed, when multiple one threaded (serial) jobs are to be sent (with different data). Slurm stores unique id of the instances in the SLURM_ARRAY_TASK_ID
enviromnemt variable. It is possible to seperate threads of the array job by retrieving these ids. Output of the threads are written into slurm-SLURM_ARRAY_JOB_ID-SLURM_ARRAY_TASK_ID.out
files. The scheduler uploads outputs tightly. It is useful to use multiply threads for a CPU core. More on this topic
Example
Alice user submits 96 serial job for a maximum of 24 hour run.
on the expenses of 'foobar' account. The #SBATCH --array=1-96
directive indicates, that it is an array job. The application
can be run with the srun
command. This is a shell script in this example.
#!/bin/bash
#SBATCH -A foobar
#SBATCH --time=24:00:00
#SBATCH --job-name=array
#SBATCH --array=1-96
srun envtest.sh
MPI jobs
Using MPI jobs, the number of MPI processes running on a node is to be given (#SBATCH --ntasks-per-node=
). The most frequent case is to provide the number of CPU cores. Parallel programs should be started by using mpirun
command.
Example
Bob user allocates 2 nodes, 12 hour for an MPI job, billing 'barfoo' account. 24 MPI thread will be started on each node. The stdout output is piped to slurm.out
file (#SBATCH -o
).
#!/bin/bash
#SBATCH -A barfoo
#SBATCH --job-name=mpi
#SBATCH -N 2
#SBATCH --ntasks-per-node=24
#SBATCH --time=12:00:00
#SBATCH -o slurm.out
mpirun ./a.out
CPU binding
Generally, the performance of MPI application can be optimized with CPU core binding. In this case, the threads of the paralel program won't be scheduled by the OS between the CPU cores, and the memory localization can be made better (less cache miss). It is advised to use memory binding. Tests can be run to define, what binding strategy gives the best performance for our application. The following settings are valid for OpenMPI environment. Further information on binding can be retrieved with --report-bindings
MPI option. Along with the running commands, few lines of the detailed binding information are shown. It is important, that one should not use task_binding of the scheduler!
Binding per CPU core
In this case, MPI fills CPU cores by the order of threads (rank).
Command to run: mpirun --bind-to-core --bycore
[cn05:05493] MCW rank 0 bound to socket 0[core 0]: [B . . . . . . . . . . .][. . . . . . . . . . . .]
[cn05:05493] MCW rank 1 bound to socket 0[core 1]: [. B . . . . . . . . . .][. . . . . . . . . . . .]
[cn05:05493] MCW rank 2 bound to socket 0[core 2]: [. . B . . . . . . . . .][. . . . . . . . . . . .]
[cn05:05493] MCW rank 3 bound to socket 0[core 3]: [. . . B . . . . . . . .][. . . . . . . . . . . .]
Binding based on CPU socket
In this case, MPI threads are filling CPUs alternately.
Command to run: mpirun --bind-to-core --bysocket
[cn05:05659] MCW rank 0 bound to socket 0[core 0]: [B . . . . . . . . . . .][. . . . . . . . . . . .]
[cn05:05659] MCW rank 1 bound to socket 1[core 0]: [. . . . . . . . . . . .][B . . . . . . . . . . .]
[cn05:05659] MCW rank 2 bound to socket 0[core 1]: [. B . . . . . . . . . .][. . . . . . . . . . . .]
[cn05:05659] MCW rank 3 bound to socket 1[core 1]: [. . . . . . . . . . . .][. B . . . . . . . . . .]
Binding by nodes
In this case, MPI threads are filling nodes alternately. At least 2 nodes needs to be allocated.
Command to run: mpirun --bind-to-core --bynode
[cn05:05904] MCW rank 0 bound to socket 0[core 0]: [B . . . . . . . . . . .][. . . . . . . . . . . .]
[cn05:05904] MCW rank 2 bound to socket 0[core 1]: [. B . . . . . . . . . .][. . . . . . . . . . . .]
[cn06:05969] MCW rank 1 bound to socket 0[core 0]: [B . . . . . . . . . . .][. . . . . . . . . . . .]
[cn06:05969] MCW rank 3 bound to socket 0[core 1]: [. B . . . . . . . . . .][. . . . . . . . . . . .]
OpenMP (OMP) jobs
For OpenMP paralell applications, 1 node needs to be allocated, and the number of OMP threads needs to be provided with the OMP_NUM_THREADS
environment variable. The variable needs to be written before the application (see example), or needs to be exported before executing the command:
export OMP_NUM_THREADS=24
Example
Alice user starts a 24 threaded OMP application for maximum 6 hours on the expenses of foobar account.
#!/bin/bash
#SBATCH -A foobar
#SBATCH --job-name=omp
#SBATCH --time=06:00:00
#SBATCH -N 1
OMP_NUM_THREADS=24 ./a.out
Hybrid MPI-OMP jobs
When an application uses MPI and OMP it is running in hybrid MPI-OMP mode. Good to know that Intel MKL linked applications MKL calls are OpenMP capable. Generally, the following distribution suggested: MPI process number is from 1 to the CPU socket number, OMP thread number is the number of CPU cores in a node, or the half or quarter of that (it depends on code). For the job script, the parameters of these two needs to be combined.
Example
Alice user sent a hybrid job on the expenses of the 'foobar' account for 8 hours, and 2 nodes. 1 MPI process is running on one node using 24 OMP thread per node. For the 2 nodes, 2 MPI process is running, with 2x24 OMP threads
#!/bin/bash
#SBATCH -A foobar
#SBATCH --job-name=mpiomp
#SBATCH -N 2
#SBATCH --time=08:00:00
#SBATCH --ntasks-per-node=1
#SBATCH -o slurm.out
export OMP_NUM_THREADS=24
mpirun ./a.out
Maple Grid jobs
Maple can be run - similarly to OMP jobs - on one node. Maple module need to be loaded for using it. A grid server needs to be started, because Maple is working in client-server mode (${MAPLE}/toolbox/Grid/bin/startserver
). This application needs to use license, which have to be given in the jobscript (#SBATCH --licenses=maplegrid:1
). Starting of a Maple job is done by using
${MAPLE}/toolbox/Grid/bin/joblauncher
code.
Example
Alice user is running a Maple Grid application for 6 hours on the expenses of 'foobar' account:
#!/bin/bash
#SBATCH -A foobar
#SBATCH --job-name=maple
#SBATCH -N 1
#SBATCH --ntasks-per-node=24
#SBATCH --time=06:00:00
#SBATCH -o slurm.out
#SBATCH --licenses=maplegrid:1
module load maple
${MAPLE}/toolbox/Grid/bin/startserver
${MAPLE}/toolbox/Grid/bin/joblauncher ${MAPLE}/toolbox/Grid/samples/Simple.mpl
GPU compute nodes
The Szeged site accomodates 2 GPU enabled compute nodes. Each GPU node has 6 Nvidia Tesla M2070 cards. The GPU nodes reside in a separate job queue (--partition gpu
). To specify the number of GPUs set --gres gpu:#
directive.
Example
Alice user submits to the foobar account a 4 GPU, 6 hour job.
#!/bin/bash
#SBATCH -A foobar
#SBATCH --job-name=GPU
#SBATCH --partition gpu
#SBATCH --gres gpu:4
#SBATCH --time=06:00:00
$PWD/gpu_burnout 3600
Extensions
Extensions should be asked for at the Execution site (NIIF) at prace-support@niif.hu. All requests will be carefully reviewed and decided if eligable.
Reporting after finishing project
A report must be created after using PRACE resources. Please contact prace-support@niif.hu for further details.
Acknowledgement in publications
PRACE
We acknowledge [PRACE/KIFÜ] for awarding us access to resource based in Hungary at [Budapest/Debrecen/Pécs/Szeged].
KIFÜ
We acknowledge KIFÜ for awarding us access to resource based in Hungary at [Budapest/Debrecen/Pécs/Szeged].
Where technical support has been received the following additional text should also be used: The support of [name of person/people] from KIFÜ, Hungary to the technical work is gratefully acknowledged.
Budapest2_klaszter
Klaszter | Budapest2 |
---|---|
Típus | HP SL250s |
core / node | 10 × 2 Xeon E5-2680v2 2.80GHz |
Intel Xeon Phi / node | 2 × Intel(R) Xeon Phi(TM) MIC SE10/7120P |
Compute node-ok | 14 db |
Max Walltime | 7-00:00:00 |
Max core-ok / projekt | 140 (7db node) |
Max mem / core | 3000 MB |
Belépés
ssh USER@login.budapest2.hpc.niif.hu
Nem alapértelmezett kulcs használata esetén a -i KULCS
kapcsolóval megadása szükséges (SSH és SCP parancsok).
Fájlok másolása SCP-vel
Letöltés a HOME könyvtárból és feltöltés a HOME könyvtárba:
Fel: scp FILE USER@login.budapest2.hpc.niif.hu:FILE
Le : scp USER@login.budapest2.hpc.niif.hu:FILE FILE
Adatszinkronizáció
Nagyobb fájlok ill. könyvtárstruktúrák szinkronizálásához a következő parancsokat kell használni
Fel: rsync -a -e ssh DIRECTORY USER@login.budapest2.hpc.niif.hu:/home/USER
Le : rsync -a -e ssh USER@login.budapest2.hpc.niif.hu:/home/USER/DIRECTORY
A törölt fájlok szinkronizálásához a --delete
opciót kell megadni.
Felhasználói felület
rövid CWD
|
BUDAPEST2[login] ~ (0)$
| | |
HPC állomás | |
rövid gép név |
előző parancs exit kódja
Modul környezet
Az elérhető modulok listáját a következő paranccsal kapjuk meg:
module avail
a már betöltött modulok listáját:
module list
Alkalmazást a következő paranccsal tölthetünk be:
module load APP
A NIIF által beállított környezeti változókat nce
parancs listázza ki.
Adatok megosztása projekt tagok számára
Fájlok ill. könyvtárak megosztásához ACL-eket kell beállítani. A HOME könyvtárat más felhasználó (OTHER) számára olvashatóvá, így tehetjük
setfacl -m u:OTHER:rx $HOME
Addott könyvtárat (DIRECTORY) írahtóvá:
setfacl -m u:OTHER:rxw $HOME/DIRECTORY
A kiterjesztett jogokat a következő paranccsal kérhetjük le:
getfacl $HOME/DIRECTORY
Közös home könyvtár használata
A szuperszámítógépek login gépeit összekötő közös fájlrendszer a következő könyvtár alatt található:
/mnt/fhgfs/home/$USER
Biztonsági mentést a közös könyvtárba a következő paranccsal tudunk végezni:
rsync -avuP --delete $HOME/DIRECTORY /mnt/fhgfs/home/$USER
Alkalmazások lefordítása
Mindenkitől azt kérjük, hogy először próbálja meg saját maga lefordítani az alkalmazását. Ha ez valamilyen oknál fogva mégsem sikerülne, akkor következő lépésként a magyarországi szuperszámítógép felhasználóktól érdemes kérdezni, mert nagy esély van rá hogy mások is belefutottak ugyanabba a problémába. Ezen a címen lehet őket elérni: hpc-forum kukac listserv.niif.hu
. Feliratkozni itt lehet erre a levelezőlistára. Az archívumban is érdemes utánanézni a kérdésnek. Az NIIF HPC support csak igen korlátozottan képes egyéni fordítási kérésekkel foglalkozni, de problémával felkeresheti a hpc-support kukac niif.hu
címet. Az utóbbi esetben pár napos türelmüket mindenképp kérjük válaszunkig.
Intel Xeon Phi használata
- Részletes használati és alkalmazás optimalizációs leírás
- Itt található az Intel hivatalos dokumentációja ezzel kapcsolatban
- Itt található az Intel által hivatalosan támogatott alkalmazások listája
- Itt tájékozódhatnak az Intel matematikai könyvtárainak a linkeléséről
SLURM ütemező használata
A szuperszámítógépen CPU óra (gépidő) alapú ütemezés működik. A felhasználóhoz tartozó Slurm projektek (Account) állapotáról a következő parancs ad információt:
sbalance
A második oszlopban (Usage) az egyes felhasználók elhasznált gépideje, a negyedik oszlopban pedig a számla összesített gépideje látható. Az utolsó két oszlop a maximális (Account Limit) és a még elérhető (Available) gépidőről ad tájékoztatást.
Scheduler Account Balance
---------- ----------- + ---------------- ----------- + ------------- -----------
User Usage | Account Usage | Account Limit Available (CPU hrs)
---------- ----------- + ---------------- ----------- + ------------- -----------
bob * 7 | foobar 7 | 1,000 993
alice 0 | foobar 7 | 1,000 993
A gépidő becslése
Nagyüzemi (production) futtatások előtt gépidőbecslést érdemes végezni. Ehhez a következő parancs használható:
sestimate -N NODES -t WALLTIME
ahol a NODES
a lefoglalni kívánt node-ok száma, a WALLTIME
pedig a futás maximális ideje.
Fontos, hogy a lefoglalni kívánt gépidőt a lehető legpontosabban adjuk meg, mivel az ütemező ez alapján is rangsorolja a futtatásra váró feladatokat. Általában igaz, hogy a rövidebb job hamarabb sorra kerül. Érdemes minden futás idejét utólag az sacct
paranccsal is ellenőrizni.
Állapotinformációk
Az ütemezőben lévő jobokról az squeue
, a klaszter általános állapotáról az sinfo
parancs ad tájékoztatást. Minden beküldött jobhoz egy egyedi azonosítószám (JOBID) rendelődik. Ennek ismeretében további információkat kérhetünk. Feladott vagy már futó job jellemzői:
scontrol show job JOBID
Minden job egy ún. számlázási adatbázisba (accounting) is bekerül. Ebből az adatbázisból visszakereshetők a lefuttatott feladatok jellemzői és erőforrás-felhasználás statisztikái. A részletes statisztikát a következő paranccsal tudjuk megnézni:
sacct -l -j JOBID
A felhasznált memóriáról a következő parancs ad tájékoztatást:
smemory JOBID
A lemezhasználatról pedig a
sdisk JOBID
Slurm figyelmeztető üzenetek
Resources/AssociationResourceLimit - Erőforrásra vár
AssociationJobLimit/QOSJobLimit - Nincs elég CPU idő vagy a maximális CPU szám le van foglalva
Piority - Alacsony prioritás miatt várakozik
Az utóbbi esetben, csökkenteni kell a job által lefoglalni kívánt időt. Egy adott projekt részére maximálisan 512 CPU-n futhatnak jobok egy adott időben.
Licenszek ellenőrzése
Az elérhető és éppen használt licenszekről a következő parancs ad információt:
slicenses
Karbantartás ellenőrzése
A karbantartási időablakban az ütemező nem indít új jobokat, de beküldeni lehet. A karbantartások időpontjairól a következő parancs ad tájékoztatást:
sreservations
Összesített felhasználás
Egy hónapra visszamenőleg az elfogyasztott CPU perceket a következő paranccsal kérhetjük le:
susage
Teljes fogyasztás
Ha szeretnénk tájékozódni arról, hogy egy bizony idő óta mennyi a CPU idő felhasználásunk akkor azt ezzel paranccsal tudjuk lekérdezni:
sreport -t Hours Cluster AccountUtilizationByUser Accounts=ACCOUNT Start=2015-01-01
Feladatok futtatása
Alkalmazások futtatása a szupergépeken kötegelt (batch) üzemmódban lehetséges. Ez azt jelenti, hogy minden futtatáshoz egy job szkriptet kell elkészíteni, amely tartalmazza az igényelt erőforrások leírását és a futtatáshoz szükséges parancsokat. Az ütemező paramétereit (erőforrás igények) a #SBATCH
direktívával kell megadni.
Kötelező paraméterek
A következő paramétereket minden esetben meg kell adni:
#!/bin/bash
#SBATCH -A ACCOUNT
#SBATCH --job-name=NAME
#SBATCH --time=TIME
ahol az ACCOUNT
a terhelendő számla neve (elérhető számláinkről az sbalance
parancs ad felvilágosítást), a NAME
a job rövid neve, a TIME
pedig a maximális walltime idő (DD-HH:MM:SS
). A következő időformátumok használhatók:
"minutes", "minutes:seconds", "hours:minutes:seconds", "days-hours", "days-hours:minutes" és "days-hours:minutes:seconds".
Intel Xeon Phi-k lefoglalása
A Intel Xeon Phi-k lefoglalása a következő direktívával történik:
#SBATCH --gres=mic:N
Az N
az Intel Xeon Phi-k/node számát adja meg, ami 1 és 2 lehet maximum.
Job-ok indítása
A jobok feladását a következő parancs végzi:
sbatch slurm.sh
Sikeres feladás esetén a következő kimenetet kapjuk:
Submitted batch job JOBID
ahol a JOBID
a feladat egyedi azonosítószáma.
A feladat leállítását a következő parancs végzi:
scancel JOBID
Nem újrainduló jobok
Nem újrainduló jobokhoz a következő direktívát kell használni:
#SBATCH --no-requeue
Feladat sorok
A szupergépeken két, egymást nem átfedő, sor (partíció) áll rendelkezésre, a test
sor és a prod
sor. Utóbbi az éles számolásokra való, előbbi fejlesztés és tesztelés céljára használható. A teszt sorban összesen 1 node-ot, maximum fél órára lehet lefoglalni. Az alapértelmezett sor a prod
. A teszt partíciót a következő direktívával lehet kiválasztani:
#SBATCH --partition=test
A szolgáltatás minősége (QOS)
A szolgáltatást alapértelmezett minősége normal
, azaz nem megszakítható a futás.
Magas prioritás
A magas prioritású jobok maximum 24 óráig futhatnak, és kétszer gyorsabb időelszámolással rendelkeznek, cserébe az ütemező előreveszi ezeket a feladatokat.
#SBATCH --qos=fast
Alacsony prioritás
Lehetőség van alacsony prioritású jobok feladására is. Az ilyen feladatokat bármilyen normál prioritású job bármikor megszakíthatja, cserébe az elhasznált gépidő fele számlázódik csak. A megszakított jobok automatikusan újraütemeződnek. Fontos, hogy olyan feladatokat indítsunk alacsony prioritással, amelyek kibírják a véletlenszerű megszakításokat, rendszeresen elmentik az állapotukat (checkpoint) és ebből gyorsan újra tudnak indulni.
#SBATCH --qos=lowpri
Memória foglalás
Alapértelmezetten 1 CPU core-hoz 1000 MB memória van rendelve, ennél többet a következő direktívával igényelhetünk:
#SBATCH --mem-per-cpu=MEMORY
ahol MEMORY
MB egységben van megadva. A maximális memória/core 3000 MB lehet.
Amennyiben a szálaknak 4GB-nál több virtuális memóriára van szükségük, akkor az indítandó program elé a következő parancsot is el kell helyezni:
ulimit -v unlimited
Email értesítés
Levél küldése job állapotának változásakor (elindulás,leállás,hiba):
#SBATCH --mail-type=ALL
#SBATCH --mail-user=EMAIL
ahol az EMAIL
az értesítendő emial cím.
Tömbfeladatok (arrayjob)
Tömbfeladatokra akkor van szükségünk, egy szálon futó (soros) alkalmazást szeretnénk egyszerre sok példányban (más-más adatokkal) futtatni. A példányok számára az ütemező a SLURM_ARRAY_TASK_ID
környezeti változóban tárolja az egyedi azonosítót. Ennek lekérdezésével lehet az arrayjob szálait elkülöníteni. A szálak kimenetei a slurm-SLURM_ARRAY_JOB_ID-SLURM_ARRAY_TASK_ID.out
fájlokba íródnak. Az ütemező a feltöltést szoros pakolás szerint végzi. Ebben az esetben is érdemes a processzorszám többszörösének választani a szálak számát. Bővebb ismertető
#!/bin/bash
#SBATCH -A ACCOUNT
#SBATCH --job-name=array
#SBATCH --time=24:00:00
#SBATCH --array=1-96
srun envtest.sh
Soros (serial) jobok
Több soros job futtatását a tömbfeladatokhoz hasonlóan kell indítani.
#!/bin/bash
#SBATCH -A ACCOUNT
#SBATCH --job-name=serial
#SBATCH --time=24:30:00
#SBATCH -n 3
#SBATCH --partition=test
srun -n 1 program input1 &
srun -n 1 program input2 &
srun -n 1 program input3
wait
IntelMPI feladatok
MPI feladatok esetén meg kell adnunk az egy node-on elinduló MPI processzek számát is (#SBATCH --ntasks-per-node=
). A leggyakoribb esetben ez az egy node-ban található CPU core-ok száma. A párhuzamos programot az mpirun
paranccsal kell indítani.
#!/bin/bash
#SBATCH -A ACCOUNT
#SBATCH --job-name=mpi
#SBATCH -N 2
#SBATCH --ntasks-per-node=20
#SBATCH --time=12:00:00
mpirun PROGRAM
OpenMPI FAQ: http://www.open-mpi.org/faq
OpenMP (OMP) feladatok
OpenMP párhuzamos alkalmazásokhoz maximum 1 node-ot lehet lefoglalni. Az OMP szálák számát az OMP_NUM_THREADS
környezeti változóval kell megadni. A változót vagy az alkamazás elé kell írni (ld. példa), vagy exportálni kell az indító parancs előtt:
export OMP_NUM_THREADS=10
A következő példában egy taskhoz 10 CPU core-t rendeltunk, a 10 CPU core-nak egy node-on kell lennie. A CPU core-ok számát a SLURM_CPUS_PER_TASK
változó tartalmazza, és ez állítja be az OMP szálak számát is.
Alice felhasználó a foobar számla terhére, maximum 6 órára indít el egy 10 szálas OMP alkalmazást.
#!/bin/bash
#SBATCH -A foobar
#SBATCH --job-name=omp
#SBATCH --time=06:00:00
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=10
OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK ./a.out
Hibrid MPI-OMP feladatok
Hibrid MPI-OMP módról akkor beszélünk, ha a párhuzamos alkalmazás MPI-t és OMP-t is használ. Érdemes tudni, hogy az Intel MKL-el linkelt programok MKL hívásai OpenMP képesek. Általában a következő elosztás javasolt: az MPI processzek száma 1-től az egy node-ban található CPU foglalatok száma, az OMP szálak ennek megfelelően az egy node-ban található összes CPU core szám vagy annak fele, negyede (értelem szerűen). A jobszkipthez a fenti két mód paramétereit kombinálni kell.
A következő példában 2 node-ot, és node-onként 1-1 taskot indítunk taskonként 10 szállal. Alice felhasználó a foobar számla terhére, 8 órára, 2 node-ra küldött be egy hibrid jobot. Egy node-on egyszerre csak 1 db MPI processz fut ami node-onként 10 OMP szálat használ. A 2 gépen összesen 2 MPI proceszz és 2 x 10 OMP szál fut.
#!/bin/bash
#SBATCH -A foobar
#SBATCH --job-name=mpiomp
#SBATCH --time=08:00:00
#SBATCH -N 2
#SBATCH --ntasks=2
#SBATCH --ntasks-per-node=1
#SBATCH --cpus-per-task=10
#SBATCH -o slurm.out
export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK
mpirun ./a.out
Miskolc_UV_2000
ccNUMA | Miskolc |
---|---|
Típus | SGI UV 2000 |
CPU / node | 44 × Intel Xeon E5-4627 v2 @ 3.33 GHz |
Compute node-ok | 1 db |
Max Walltime | 7-00:00:00 |
Max mem / core | 3750 MB |
Belépés
ssh USER@login.miskolc.hpc.niif.hu
Nem alapértelmezett kulcs használata esetén a -i KULCS
kapcsolóval megadása szükséges (SSH és SCP parancsok).
Fájlok másolása SCP-vel
Letöltés a HOME könyvtárból és feltöltés a HOME könyvtárba:
Fel: scp FILE USER@login.miskolc.hpc.niif.hu:FILE
Le : scp USER@login.miskolc.hpc.niif.hu:FILE FILE
Adatszinkronizáció
Nagyobb fájlok ill. könyvtárstruktúrák szinkronizálásához a következő parancsokat kell használni
Fel: rsync -a -e ssh DIRECTORY USER@login.miskolc.hpc.niif.hu:/home/USER
Le : rsync -a -e ssh USER@login.miskolc.hpc.niif.hu:/home/USER/DIRECTORY
A törölt fájlok szinkronizálásához a --delete
opciót kell megadni.
Felhasználói felület
rövid CWD
|
MISKOLC[login] ~ (0)$
| | |
HPC állomás | |
rövid gép név |
előző parancs exit kódja
Modul környezet
Az elérhető modulok listáját a következő paranccsal kapjuk meg:
module avail
a már betöltött modulok listáját:
module list
Alkalmazást a következő paranccsal tölthetünk be:
module load APP
A NIIF által beállított környezeti változókat nce
parancs listázza ki.
Adatok megosztása projekt tagok számára
Fájlok ill. könyvtárak megosztásához ACL-eket kell beállítani. A HOME könyvtárat más felhasználó (OTHER) számára olvashatóvá, így tehetjük
setfacl -m u:OTHER:rx $HOME
Addott könyvtárat (DIRECTORY) írahtóvá:
setfacl -m u:OTHER:rxw $HOME/DIRECTORY
A kiterjesztett jogokat a következő paranccsal kérhetjük le:
getfacl $HOME/DIRECTORY
Alkalmazások lefordítása
Mindenkitől azt kérjük, hogy először próbálja meg saját maga lefordítani az alkalmazását. Ha ez valamilyen oknál fogva mégsem sikerülne, akkor következő lépésként a magyarországi szuperszámítógép felhasználóktól érdemes kérdezni, mert nagy esély van rá hogy mások is belefutottak ugyanabba a problémába. Ezen a címen lehet őket elérni: hpc-forum kukac listserv.niif.hu
. Feliratkozni itt lehet erre a levelezőlistára. Az archívumban is érdemes utánanézni a kérdésnek. Az NIIF HPC support csak igen korlátozottan képes egyéni fordítási kérésekkel foglalkozni, de problémával felkeresheti a hpc-support kukac niif.hu
címet. Az utóbbi esetben pár napos türelmüket mindenképp kérjük válaszunkig.
SLURM ütemező használata
A szuperszámítógépen CPU óra (gépidő) alapú ütemezés működik. A felhasználóhoz tartozó Slurm projektek (Account) állapotáról a következő parancs ad információt:
sbalance
A második oszlopban (Usage) az egyes felhasználók elhasznált gépideje, a negyedik oszlopban pedig a számla összesített gépideje látható. Az utolsó két oszlop a maximális (Account Limit) és a még elérhető (Available) gépidőről ad tájékoztatást.
Scheduler Account Balance
---------- ----------- + ---------------- ----------- + ------------- -----------
User Usage | Account Usage | Account Limit Available (CPU hrs)
---------- ----------- + ---------------- ----------- + ------------- -----------
bob * 7 | foobar 7 | 1,000 993
alice 0 | foobar 7 | 1,000 993
A gépidő becslése
Nagyüzemi (production) futtatások előtt gépidőbecslést érdemes végezni. Ehhez a következő parancs használható:
sestimate -c CORES -t WALLTIME
ahol a CORES
a lefoglalni kívánt core-ok száma, amelynek 8 többszörösének kell lenni. 8 core-hoz 30 GByte memória tartozik. Ha több memóriára van szükségünk, akkor meg kell növelni a core-ok számát. A WALLTIME
pedig a futás maximális ideje.
Fontos, hogy a lefoglalni kívánt gépidőt a lehető legpontosabban adjuk meg, mivel az ütemező ez alapján is rangsorolja a futtatásra váró feladatokat. Általában igaz, hogy a rövidebb job hamarabb sorra kerül. Érdemes minden futás idejét utólag az sacct
paranccsal is ellenőrizni.
Állapotinformációk
Az ütemezőben lévő jobokról az squeue
, a klaszter általános állapotáról az sinfo
parancs ad tájékoztatást. Minden beküldött jobhoz egy egyedi azonosítószám (JOBID) rendelődik. Ennek ismeretében további információkat kérhetünk. Feladott vagy már futó job jellemzői:
scontrol show job JOBID
Minden job egy ún. számlázási adatbázisba (accounting) is bekerül. Ebből az adatbázisból visszakereshetők a lefuttatott feladatok jellemzői és erőforrás-felhasználás statisztikái. A részletes statisztikát a következő paranccsal tudjuk megnézni:
sacct -l -j JOBID
A felhasznált memóriáról a következő parancs ad tájékoztatást:
smemory JOBID
A lemezhasználatról pedig a
sdisk JOBID
Slurm figyelmeztető üzenetek
Resources/AssociationResourceLimit - Erőforrásra vár
AssociationJobLimit/QOSJobLimit - Nincs elég CPU idő vagy a maximális CPU szám le van foglalva
Piority - Alacsony prioritás miatt várakozik
Az utóbbi esetben, csökkenteni kell a job által lefoglalni kívánt időt.
Licenszek ellenőrzése
Az elérhető és éppen használt licenszekről a következő parancs ad információt:
slicenses
Karbantartás ellenőrzése
A karbantartási időablakban az ütemező nem indít új jobokat, de beküldeni lehet. A karbantartások időpontjairól a következő parancs ad tájékoztatást:
sreservations
Összesített felhasználás
Egy hónapra visszamenőleg az elfogyasztott CPU perceket a következő paranccsal kérhetjük le:
susage
Teljes fogyasztás
Ha szeretnénk tájékozódni arról, hogy egy bizony idő óta mennyi a CPU idő felhasználásunk akkor azt ezzel paranccsal tudjuk lekérdezni:
sreport -t Hours Cluster AccountUtilizationByUser Accounts=ACCOUNT Start=2015-01-01
Feladatok futtatása
Alkalmazások futtatása a szupergépeken kötegelt (batch) üzemmódban lehetséges. Ez azt jelenti, hogy minden futtatáshoz egy job szkriptet kell elkészíteni, amely tartalmazza az igényelt erőforrások leírását és a futtatáshoz szükséges parancsokat. Az ütemező paramétereit (erőforrás igények) a #SBATCH
direktívával kell megadni.
Kötelező paraméterek
A következő paramétereket minden esetben meg kell adni:
#!/bin/bash
#SBATCH -A ACCOUNT
#SBATCH --job-name=NAME
#SBATCH --time=TIME
ahol az ACCOUNT
a terhelendő számla neve (elérhető számláinkről az sbalance
parancs ad felvilágosítást), a NAME
a job rövid neve, a TIME
pedig a maximális walltime idő (DD-HH:MM:SS
). A következő időformátumok használhatók:
"minutes", "minutes:seconds", "hours:minutes:seconds", "days-hours", "days-hours:minutes" és "days-hours:minutes:seconds".
Job-ok indítása
Az egyetlen elfogadott paraméter a szálak száma (-n
), amelynek 8 többszörösének kell lennie. 8 szálhoz 30 GByte memória tartozik. Ha több memóriára van szükségünk, akkor meg kell növelni a szálak számát. Egy szálú ill. array jobok futtatása nem lehetséges.
A jobok feladását a következő parancs végzi:
sbatch slurm.sh
Sikeres feladás esetén a következő kimenetet kapjuk:
Submitted batch job JOBID
ahol a JOBID
a feladat egyedi azonosítószáma.
A feladat leállítását a következő parancs végzi:
scancel JOBID
Nem újrainduló jobok
Nem újrainduló jobokhoz a következő direktívát kell használni:
#SBATCH --no-requeue
A szolgáltatás minősége (QOS)
A szolgáltatást alapértelmezett minősége normal
, azaz nem megszakítható a futás. A gépen lévő QOS limitek részletes paramétereit így tudjuk kilistázni:
sacctmgr show qos
Alacsony prioritás
Lehetőség van alacsony prioritású jobok feladására is. Az ilyen feladatokat bármilyen normál prioritású job bármikor megszakíthatja, cserébe az elhasznált gépidő fele számlázódik csak. A megszakított jobok automatikusan újraütemeződnek. Fontos, hogy olyan feladatokat indítsunk alacsony prioritással, amelyek kibírják a véletlenszerű megszakításokat, rendszeresen elmentik az állapotukat (checkpoint) és ebből gyorsan újra tudnak indulni.
#SBATCH --qos=lowpri
Magas prioritás
A magas prioritású jobok maximum 24 óráig futhatnak, és kétszer gyorsabb időelszámolással rendelkeznek, cserébe az ütemező előreveszi ezeket a feladatokat.
#SBATCH --qos=fast
Tesztelés
Teszt job bekuldesehez a --qos=test opciot kell hasznalni a job scriptben. Ebben az esetben maximum 30 percig futhat a job es osszesen 24 szal kerheto.
#SBATCH --qos=test
Email értesítés
Levél küldése job állapotának változásakor (elindulás,leállás,hiba):
#SBATCH --mail-type=ALL
#SBATCH --mail-user=EMAIL
ahol az EMAIL
az értesítendő emial cím.
OpenMP Példa
#!/bin/bash
#SBATCH -A barfoo
#SBATCH --job-name=omp
#SBATCH -n 48
#SBATCH --time=03:00:00
#SBATCH -o slurm.out
/opt/nce/bin/numainfo
OMP_NUM_THREADS=$SLURM_NTASKS ./a.out
SGI MPT MPI Példa
#!/bin/bash
#SBATCH -A barfoo
#SBATCH --job-name=omp
#SBATCH -n 48
#SBATCH --time=03:00:00
#SBATCH -o slurm.out
/opt/nce/bin/numainfo
mpirun $SLURM_NTASKS ./a.out
Debrecen2_Phi_klaszter
Klaszter | Debrecen3 Phi (Apollo) |
---|---|
Típus | HP Apollo 8000 |
core / node | 12 × 2 Intel Xeon E5-2670 v3 @ 2.30GHz |
MIC / node | 44 x 2 Intel(R) Xeon Phi(TM) MIC SE10/7120D |
Compute node-ok | 44 db |
Max Walltime | 7-00:00:00 |
Max core-ok / projekt | 336 |
Max mem / core | 5000 MB |
CPU idő kérés
!!! tip
A CPU idő igénylésekor egy olyan rövid indoklást várunk a HPC projekt vezetőktől, amiből kiderül, hogy a futtatandó alkalmazás képes MIC-et használni (ez alól kivétel, ha a felhasználás célja a gépen elérhető licenszelt szoftver használata, amennyiben az nem képes Phi-t használni (pl. Gaussian, Maple)). Erre azért van szükség, mert az erőforrás teljesítményének nagyobbik része Phi gyorsításból származik, egy gyorsítás nélküli program a CPU-kat lefoglalja, korlátozva ezzel a Phi-k használatát, ami kihasználatlansághoz vezet. Az Intel [közzétett egy listát](https://software.intel.com/en-us/xeonphionlinecatalog) arról, hogy melyik alkalmazás rendelkezik jelenleg hivatalosan Intel Xeon Phi támogatással, de természetesen egyéb, Phi-t használó program is nagy valószínűséggel jól fut a gépen.
Belépés
ssh USER@login.debrecen2.hpc.niif.hu
Nem alapértelmezett kulcs használata esetén a -i KULCS
kapcsolóval megadása szükséges (SSH és SCP parancsok).
Fájlok másolása SCP-vel
Letöltés a HOME könyvtárból és feltöltés a HOME könyvtárba:
Fel: scp FILE USER@login.debrecen2.hpc.niif.hu:FILE
Le : scp USER@login.debrecen2.hpc.niif.hu:FILE FILE
Adatszinkronizáció
Nagyobb fájlok ill. könyvtárstruktúrák szinkronizálásához a következő parancsokat kell használni
Fel: rsync -a -e ssh DIRECTORY USER@login.debrecen2.hpc.niif.hu:/home/USER
Le : rsync -a -e ssh USER@login.debrecen2.hpc.niif.hu:/home/USER/DIRECTORY
A törölt fájlok szinkronizálásához a --delete
opciót kell megadni.
Felhasználói felület
rövid CWD
|
DEBRECEN2[login] ~ (0)$
| | |
HPC állomás | |
rövid gép név |
előző parancs exit kódja
Modul környezet
Az elérhető modulok listáját a következő paranccsal kapjuk meg:
module avail
a már betöltött modulok listáját:
module list
Alkalmazást a következő paranccsal tölthetünk be:
module load APP
A NIIF által beállított környezeti változókat nce
parancs listázza ki.
Adatok megosztása projekt tagok számára
Fájlok ill. könyvtárak megosztásához ACL-eket kell beállítani. A HOME könyvtárat más felhasználó (OTHER) számára olvashatóvá, így tehetjük
setfacl -m u:OTHER:rx $HOME
Addott könyvtárat (DIRECTORY) írahtóvá:
setfacl -m u:OTHER:rxw $HOME/DIRECTORY
A kiterjesztett jogokat a következő paranccsal kérhetjük le:
getfacl $HOME/DIRECTORY
Közös home könyvtár használata
A szuperszámítógépek login gépeit összekötő közös fájlrendszer a következő könyvtár alatt található:
/mnt/fhgfs/home/$USER
Biztonsági mentést a közös könyvtárba a következő paranccsal tudunk végezni:
rsync -avuP --delete $HOME/DIRECTORY /mnt/fhgfs/home/$USER
Alkalmazások lefordítása
Mindenkitől azt kérjük, hogy először próbálja meg saját maga lefordítani az alkalmazását. Ha ez valamilyen oknál fogva mégsem sikerülne, akkor következő lépésként a magyarországi szuperszámítógép felhasználóktól érdemes kérdezni, mert nagy esély van rá hogy mások is belefutottak ugyanabba a problémába. Ezen a címen lehet őket elérni: hpc-forum kukac listserv.niif.hu
. Feliratkozni itt lehet erre a levelezőlistára. Az archívumban is érdemes utánanézni a kérdésnek. Az NIIF HPC support csak igen korlátozottan képes egyéni fordítási kérésekkel foglalkozni, de problémával felkeresheti a hpc-support kukac niif.hu
címet. Az utóbbi esetben pár napos türelmüket mindenképp kérjük válaszunkig.
SLURM ütemező használata
A szuperszámítógépen CPU óra (gépidő) alapú ütemezés működik. A felhasználóhoz tartozó Slurm projektek (Account) állapotáról a következő parancs ad információt:
sbalance
A második oszlopban (Usage) az egyes felhasználók elhasznált gépideje, a negyedik oszlopban pedig a számla összesített gépideje látható. Az utolsó két oszlop a maximális (Account Limit) és a még elérhető (Available) gépidőről ad tájékoztatást.
Scheduler Account Balance
---------- ----------- + ---------------- ----------- + ------------- -----------
User Usage | Account Usage | Account Limit Available (CPU hrs)
---------- ----------- + ---------------- ----------- + ------------- -----------
bob * 7 | foobar 7 | 1,000 993
alice 0 | foobar 7 | 1,000 993
A gépidő becslése
Nagyüzemi (production) futtatások előtt gépidőbecslést érdemes végezni. Ehhez a következő parancs használható:
sestimate -N NODES -t WALLTIME
ahol a NODES
a lefoglalni kívánt node-ok száma, a WALLTIME
pedig a futás maximális ideje.
Fontos, hogy a lefoglalni kívánt gépidőt a lehető legpontosabban adjuk meg, mivel az ütemező ez alapján is rangsorolja a futtatásra váró feladatokat. Általában igaz, hogy a rövidebb job hamarabb sorra kerül. Érdemes minden futás idejét utólag az sacct
paranccsal is ellenőrizni.
Állapotinformációk
Az ütemezőben lévő jobokról az squeue
, a klaszter általános állapotáról az sinfo
parancs ad tájékoztatást. Minden beküldött jobhoz egy egyedi azonosítószám (JOBID) rendelődik. Ennek ismeretében további információkat kérhetünk. Feladott vagy már futó job jellemzői:
scontrol show job JOBID
Minden job egy ún. számlázási adatbázisba (accounting) is bekerül. Ebből az adatbázisból visszakereshetők a lefuttatott feladatok jellemzői és erőforrás-felhasználás statisztikái. A részletes statisztikát a következő paranccsal tudjuk megnézni:
sacct -l -j JOBID
A felhasznált memóriáról a következő parancs ad tájékoztatást:
smemory JOBID
A lemezhasználatról pedig a
sdisk JOBID
Slurm figyelmeztető üzenetek
Resources/AssociationResourceLimit - Erőforrásra vár
AssociationJobLimit/QOSJobLimit - Nincs elég CPU idő vagy a maximális CPU szám le van foglalva
Piority - Alacsony prioritás miatt várakozik
Az utóbbi esetben, csökkenteni kell a job által lefoglalni kívánt időt. Egy adott projekt részére maximálisan 512 CPU-n futhatnak jobok egy adott időben.
Licenszek ellenőrzése
Az elérhető és éppen használt licenszekről a következő parancs ad információt:
slicenses
Karbantartás ellenőrzése
A karbantartási időablakban az ütemező nem indít új jobokat, de beküldeni lehet. A karbantartások időpontjairól a következő parancs ad tájékoztatást:
sreservations
Összesített felhasználás
Egy hónapra visszamenőleg az elfogyasztott CPU perceket a következő paranccsal kérhetjük le:
susage
Teljes fogyasztás
Ha szeretnénk tájékozódni arról, hogy egy bizony idő óta mennyi a CPU idő felhasználásunk akkor azt ezzel paranccsal tudjuk lekérdezni:
sreport -t Hours Cluster AccountUtilizationByUser Accounts=ACCOUNT Start=2015-01-01
Feladatok futtatása
Alkalmazások futtatása a szupergépeken kötegelt (batch) üzemmódban lehetséges. Ez azt jelenti, hogy minden futtatáshoz egy job szkriptet kell elkészíteni, amely tartalmazza az igényelt erőforrások leírását és a futtatáshoz szükséges parancsokat. Az ütemező paramétereit (erőforrás igények) a #SBATCH
direktívával kell megadni.
Kötelező paraméterek
A következő paramétereket minden esetben meg kell adni:
#!/bin/bash
#SBATCH -A ACCOUNT
#SBATCH --job-name=NAME
#SBATCH --time=TIME
ahol az ACCOUNT
a terhelendő számla neve (elérhető számláinkről az sbalance
parancs ad felvilágosítást), a NAME
a job rövid neve, a TIME
pedig a maximális walltime idő (DD-HH:MM:SS
). A következő időformátumok használhatók:
"minutes", "minutes:seconds", "hours:minutes:seconds", "days-hours", "days-hours:minutes" és "days-hours:minutes:seconds".
Phi-k lefoglalása
A Phi-k lefoglalása a következő direktívával törénik:
#SBATCH --gres=mic:N
Az N
a Phi-k/node számát adja meg, ami 1 vagy 2 lehet.
Interaktív használat
Rövid interaktív feladatokat az 'srun' paranccsal tudunk beküldeni, pl.:
srun -l -n 1 -t TIME --gres=mic:1 -A ACCOUNT APP
!!! info
A Xeon Phi gyorsítók használatról, programozásáról és optimalizálásról [készítettünk egy wiki oldalt](https://help.edu.hu/books/hpc/page/intel-xeon-phi)
Batch job-ok indítása
A jobok feladását a következő parancs végzi:
sbatch slurm.sh
Sikeres feladás esetén a következő kimenetet kapjuk:
Submitted batch job JOBID
ahol a JOBID
a feladat egyedi azonosítószáma.
A feladat leállítását a következő parancs végzi:
scancel JOBID
Nem újrainduló jobok
Nem újrainduló jobokhoz a következő direktívát kell használni:
#SBATCH --no-requeue
Feladat sorok
A szupergépen login node-ja megegyezik a Debrecen2 GPU login node-jával, a Debrecen2 Phi gép használata a megfelelő várakozási sor megadásával lehetséges. A várakozási sor neve:
prod-phi
A partíciót a következő direktívával lehet kiválasztani:
#SBATCH --partition=prod-phi
A szolgáltatás minősége (QOS)
A szolgáltatást alapértelmezett minősége normal
, azaz nem megszakítható a futás.
Magas prioritás
A magas prioritású jobok maximum 24 óráig futhatnak, és kétszer gyorsabb időelszámolással rendelkeznek, cserébe az ütemező előreveszi ezeket a feladatokat.
#SBATCH --qos=fast
Alacsony prioritás
Lehetőség van alacsony prioritású jobok feladására is. Az ilyen feladatokat bármilyen normál prioritású job bármikor megszakíthatja, cserébe az elhasznált gépidő fele számlázódik csak. A megszakított jobok automatikusan újraütemeződnek. Fontos, hogy olyan feladatokat indítsunk alacsony prioritással, amelyek kibírják a véletlenszerű megszakításokat, rendszeresen elmentik az állapotukat (checkpoint) és ebből gyorsan újra tudnak indulni.
#SBATCH --qos=lowpri
Memória foglalás
Alapértelmezetten 1 CPU core-hoz 1000 MB memória van rendelve, ennél többet a következő direktívával igényelhetünk:
#SBATCH --mem-per-cpu=MEMORY
ahol MEMORY
MB egységben van megadva. A maximális memória/core 5000 MB lehet.
Email értesítés
Levél küldése job állapotának változásakor (elindulás,leállás,hiba):
#SBATCH --mail-type=ALL
#SBATCH --mail-user=EMAIL
ahol az EMAIL
az értesítendő emial cím.
Tömbfeladatok (arrayjob)
Tömbfeladatokra akkor van szükségünk, egy szálon futó (soros) alkalmazást szeretnénk egyszerre sok példányban (más-más adatokkal) futtatni. A példányok számára az ütemező a SLURM_ARRAY_TASK_ID
környezeti változóban tárolja az egyedi azonosítót. Ennek lekérdezésével lehet az arrayjob szálait elkülöníteni. A szálak kimenetei a slurm-SLURM_ARRAY_JOB_ID-SLURM_ARRAY_TASK_ID.out
fájlokba íródnak. Az ütemező a feltöltést szoros pakolás szerint végzi. Ebben az esetben is érdemes a processzorszám többszörösének választani a szálak számát. Bővebb ismertető
#!/bin/bash
#SBATCH -A ACCOUNT
#SBATCH --job-name=array
#SBATCH --time=24:00:00
#SBATCH --array=1-96
srun envtest.sh
OpenMPI feladatok
MPI feladatok esetén meg kell adnunk az egy node-on elinduló MPI processzek számát is (#SBATCH --ntasks-per-node=
). A leggyakoribb esetben ez az egy node-ban található CPU core-ok száma. A párhuzamos programot az mpirun
paranccsal kell indítani.
#!/bin/bash
#SBATCH -A ACCOUNT
#SBATCH --job-name=mpi
#SBATCH -N 2
#SBATCH --ntasks-per-node=8
#SBATCH --time=12:00:00
mpirun --report-pid ${TMPDIR}/mpirun.pid PROGRAM
OpenMPI FAQ: http://www.open-mpi.org/faq
OpenMP (OMP) feladatok
OpenMP párhuzamos alkalmazásokhoz maximum 1 node-ot lehet lefoglalni. Az OMP szálák számát az OMP_NUM_THREADS
környezeti változóval kell megadni. A változót vagy az alkamazás elé kell írni (ld. példa), vagy exportálni kell az indító parancs előtt:
export OMP_NUM_THREADS=8
A következő példában egy taskhoz 8 CPU core-t rendeltunk, a 8 CPU core-nak egy node-on kell lennie. A CPU core-ok számát a SLURM_CPUS_PER_TASK
változó tartalmazza, és ez állítja be az OMP szálak számát is.
Alice felhasználó a foobar számla terhére, maximum 6 órára indít el egy 8 szálas OMP alkalmazást.
#!/bin/bash
#SBATCH -A foobar
#SBATCH --job-name=omp
#SBATCH --time=06:00:00
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=8
OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK ./a.out
Hibrid MPI-OMP feladatok
Hibrid MPI-OMP módról akkor beszélünk, ha a párhuzamos alkalmazás MPI-t és OMP-t is használ. Érdemes tudni, hogy az Intel MKL-el linkelt programok MKL hívásai OpenMP képesek. Általában a következő elosztás javasolt: az MPI processzek száma 1-től az egy node-ban található CPU foglalatok száma, az OMP szálak ennek megfelelően az egy node-ban található összes CPU core szám vagy annak fele, negyede (értelem szerűen). A jobszkipthez a fenti két mód paramétereit kombinálni kell.
A következő példában 2 node-ot, és node-onként 1-1 taskot indítunk taskonként 10 szállal. Alice felhasználó a foobar számla terhére, 8 órára, 2 node-ra küldött be egy hibrid jobot. Egy node-on egyszerre csak 1 db MPI processz fut ami node-onként 8 OMP szálat használ. A 2 gépen összesen 2 MPI proceszz és 2 x 8 OMP szál fut.
#!/bin/bash
#SBATCH -A foobar
#SBATCH --job-name=mpiomp
#SBATCH --time=08:00:00
#SBATCH -N 2
#SBATCH --ntasks=2
#SBATCH --ntasks-per-node=1
#SBATCH --cpus-per-task=8
#SBATCH -o slurm.out
export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK
mpirun ./a.out
Maple Grid feladatok
Maple-t az OMP feladatokhoz hasonlóan 1 node-on lehet futtatni. Használatához be kell tölteni a maple modult is. A Maple kliens-szerver üzemmódban működik ezért a Maple feladat futtatása előtt szükség van a grid szerver elindítására is (${MAPLE}/toolbox/Grid/bin/startserver
). Ez az alkalmazás licensz köteles, amit a jobszkriptben meg kell adni (#SBATCH --licenses=maplegrid:1
). A Maple feladat indátását a ${MAPLE}/toolbox/Grid/bin/joblauncher
paranccsal kell elvégezni.
Alice felhasználó a foobar számla terhére, 6 órára indítja el a Maple Grid alkalmazást:
#!/bin/bash
#SBATCH -A foobar
#SBATCH --job-name=maple
#SBATCH -N 1
#SBATCH --ntasks-per-node=16
#SBATCH --time=06:00:00
#SBATCH -o slurm.out
#SBATCH --licenses=maplegrid:1
module load maple
${MAPLE}/toolbox/Grid/bin/startserver
${MAPLE}/toolbox/Grid/bin/joblauncher ${MAPLE}/toolbox/Grid/samples/Simple.mpl
HPC_software
The current version of software on specific machines might be higher than described here. We are encouraging all users to install other tools to be used on our servers if service AUP and license restrictions are respected.
The current version of software on specific machines might be higher than described here. We are encouraging all users to install other tools to be used on our servers if service AUP and license restrictions are respected.
Software component | Debrecen | Pécs | Szeged | Budapest | Budapest2 | Debrecen2,3 (Leo, Apollo) | Miskolc |
---|---|---|---|---|---|---|---|
Compiler environment (compiler, debugger, profiler) | |||||||
AMD compilers (opencc, openf90, openf95) | - | - | - | Available | Available | - | - |
Math. Library (AMD) ACML | - | - | - | 4.2.4 | - | - | - |
GDB | 7 | 7 | 7.0.1 | 7.2 | - | - | 7.5 |
GNU compilers (gcc, g++, gfortran) | 4.3 | 4.1.2 | 4.1.2, 4.4.4 | 4.4.7 | - | 4.8.5 | - |
Gprof | 2.2 | 2.17 | 2.20 | 2.26.1 | - | - | - |
Intel compilers (icc, ifort), MKL, Linking | 12.1.5 (composerxe-2011 Update 11) | - | - | - | - | 16.0 | - |
Oprofile | - | - | - | 0.9.4 | - | - | - |
Libraries supporting parallel development | |||||||
LAM-MPI | - | - | - | 7.1.2 | - | - | - |
MPICH2 | 1.4 | 1.4 | 1.2 | - | - | - | - |
OpenMP | 2.5 (GNU), 3.0 (Intel) | 2.5 (GNU), 2.5 (AMD) | - | 2.5 (GNU), 3.0 (Intel) | - | - | - |
OpenMPI | 1.4.2 | 1.3.2 | 1.4.3 | 1.8.5 | - | 1.6.3 | - |
PVM | - | - | - | 3.4.5 | - | - | - |
SGI Perf. Suite | Available | - | - | - | Available | - | Available |
SGI-MPI (MPT) | 2.04 | - | - | - | - | 2.13 | - |
PGI Compiler and Tools | - | - | - | - | 15.10 | - | - |
Libraries supporting scientific work | |||||||
AmberTool | 16 | - | - | - | - | - | - |
Atlas | 3.8.3 | - | - | - | - | - | - |
BLACS | 1.1 (OpenMPI, MPICH2) | 1.1 (OpenMPI Intel) | - | 3.1.3 | - | - | - |
BLAS | 3.2.2 | 3 | 3.6.1 | - | - | - | 3 |
Boost | 1.36 | - | - | - | - | - | - |
FFTW | 3.1.2 | 3.2.2 | 3.3.5 | 3.3.4 | 3.3.3 | - | - |
Gromacs | 4.5.4 | 4.5.5 | - | 5.1.4 | 4.6.2 | - | - |
GUILE | 1.8.5 | - | - | - | - | 1.8.8 | - |
HDF5 | 1.8.7 | - | 1.8.14 | - | - | - | - |
LAMMPS | - | - | 16.05.14 (Phi) | 16.05.14 (GPU, Phi) | - | - | - |
Lapack | 3.2.2 | 3 | 3.6.1 | - | - | - | - |
Maple | - | 18 | - | 2015 | - | - | - |
Matlab | 7.13.0 (R2011b) | - | - | R2015b | - | - | - |
NetCDF | 4.1.3 | - | 4.2.1.1 | 4.4.1 | 4.3.3.1 | - | - |
NumPy | 1.3 | 1.7.1 | 1.11.2 | - | - | - | 1.7.0 |
PETSc | - | - | 3.7.4 Intel | - | - | - | - |
Python | 2.7.5 | - | - | 3.5.2 | - | - | - |
Octave | 3.4 | 3.0.5 | - | - | - | - | - |
Qt | 3.3.8b, 4.6.2 | - | 3.3.6 | - | - | - | - |
R | 2.8.1, 3.2.0, 3.2.5(Intel) | 2.8.1 | - | - | - | 3.0.1 | - |
Scalapack | 1.7.5 | - | 2.0.2 | - | - | - | - |
Scilab | 5.3.2 | - | - | - | - | - | - |
Scipy | 0.12.0 | 0.18.1 | - | - | - | - | - |
Sun JRE | 1.6 | - | - | 1.8 | 1.7 | - | - |
Gaussian | 09_REV_C.01 | - | - | - | - | 09_REV_D.01 | - |
Middleware | |||||||
ARC grid middleware | 4.1.0 (A-REX, ARIS, clients) | - | - | - | - | - | - |
Miscellaneous software | |||||||
Emacs | 22.3 | 21.4 | - | 23.1.1 | 22.3.1 | - | - |
GNU Plot | 4.2.3 | 4 | - | - | - | - | - |
ImageMagick | 6.4.3 | 6.2.8 | - | - | - | - | - |
Turbo VNC | 1.1 | - | - | 2 | - | - | - |
Blender | 2.49 | - | - | 2.49 | - | - | - |
VirtualGL | 2.3.2 | - | - | 2.4 | - | - | - |
Paraview | 3.14.1 | - | - | - | 3.14.1 | - | - |
ffmpeg | - | - | 0.4.9 | - | - | - | - |
HPC_vizualizacio
HPC vizualizációs infrastruktúra elérése
Vizualizációra használható szerverek:
- vserver.budapest2.hpc.niif.hu (Nvidia Quadro K5000)
- vserver.debrecen.hpc.niif.hu (Nvidia Quadro FX 5800)
- vserver.debrecen2.hpc.niif.hu (Nvidia Quadro K6000)
- vserver.pecs.hpc.niif.hu (Nvidia Quadro FX 5800)
- vserver.szeged.hpc.niif.hu (Nvidia Quadro FX 5800)
A felhasznált technológia: TurboVNC/VirtualGL További részletek: http://virtualgl.org/
A vizualizációs alrendszer eléréséhez két terminálra van szükségünk.
Terminal1:
zion:~ roczei$ ssh -A vserver.debrecen.hpc.niif.huroczei@service1:~> vncserver
You will require a password to access your desktops.
Password:
Verify:
Would you like to enter a view-only password (y/n)? n
New 'X' desktop is service1:2
Creating default startup script /home/roczei/.vnc/xstartup.turbovnc
Starting applications specified in /home/roczei/.vnc/xstartup.turbovnc
Log file is /home/roczei/.vnc/service1:2.log
VNC portot így tudjuk megnézni:
roczei@service1:~> ps aux | grep rfbport | grep roczei roczei 20408 1.3 0.0 44056 23308 ? S 18:30 0:01 /opt/TurboVNC/bin/Xvnc :2 -desktop X -httpd /opt/TurboVNC/bin/../vnc/classes -auth /home/roczei/.Xauthority -dontdisconnect -geometry 1240x900 -depth 24 -rfbwait 120000 -rfbauth /home/roczei/.vnc/passwd -otpauth -pamauth -rfbport 5902 -fp /usr/share/fonts/misc,/usr/share/fonts/75dpi,/usr/share/fonts/100dpi,/usr/share/fonts/Speedo,/usr/share/fonts/Type1 -co /usr/share/X11/rgb -deferupdate 1
roczei 21605 0.0 0.0 5532 868 pts/3 S+ 18:32 0:00 grep rfbport
roczei@service1:~>
Terminal2:
Innen tudják letölteni a TurboVNC klienst.
SSH tunnel készítése UNIX operációs rendszer alatt:
zion:~ roczei$ ssh -f -N -q -L 20000:localhost:5902 roczei@vserver.debrecen.hpc.niif.hu
SSH tunnel készítése Windows operációs rendszer alatt:
Ehhez hasonló putty beállítást kell használni Windows alatt, hogy működjön az SSH tunnel:
VNC kliens elindítása:
zion:~ roczei$ vncviewer localhost:20000 Connected to RFB server, using protocol version 3.8
Enabling TightVNC protocol extensions Performing standard VNC authentication
Password:
zion:~ roczei$
Ezután megjelenik a grafikus felület. A 3D-s kártyát használó parancsokat vglrun-al tudjuk futtatni.
Példa:
roczei@service1:~> vglrun glxgears
Ha 14 napig nincs VNC kliens aktivitás (billentyűzet leütés, egér mozgatás) akkor a vncserver automatikusan terminálódik azért, hogy ne pazarolja feleslegesen az erőforrásokat. Előfordulhat olyan eset, hogy a képernyőkímélő aktiválódik és jelszót kér. Ennek az elkerülése érdekében érdemes kikapcsolni a képernyőkímélőt. GNOME rendszer esetén a System/Preferences/Screensaver menüpont alatt az "Activate screensaver when computer is idle" beállítást kell kikapcsolni.
A vizualizációs gépeken telepítve vannak a Paraview és Blender vizualizációs alkalmazások.
A HPC oktatáson elhangzott VirtualGL-s bemuatót itt tudják megtekinteni.
Debrecen2_GPU_klaszter_en
Cluster | Debrecen2 (Leo) |
---|---|
Type | HP SL250s |
Core / node | 8 × 2 Xeon E5-2650v2 2.60GHz |
GPU / node | 68 * 3 Nvidia K20x + 16 * 3 Nvidia K40x |
# of compute nodes | 84 |
Max Walltime | 7-00:00:00 |
Max core / project | 336 |
Max mem / core | 7000 MB |
Requesting CPU time
!!! tip
When applying for CPU time, we expect a brief justification from the HPC project managers stating that the application to be run is capable of using a GPU (except when the purpose is to use licensed software – available on the machine – that is unable to use a GPU, e.g. Gaussian, Maple). This is necessary because most of the HPC resource performance comes from GPU acceleration, so a program without acceleration that allocates CPUs, would be limiting the use of GPUs leading to underutilization. NVIDIA released [**a list**](http://www.nvidia.com/object/gpu-applications.html) of applications officially supported by NVIDIA GPUs but of course other programs that use GPUs are also likely to perform well on the machine.
* For those who are interested in GPU programming we held a workshop the video materials of which are available here: [GPU programming workshop (videotorium)](http://videotorium.hu/hu/events/details/1864,GPU_programozas_workshop)
Login
ssh USER@login.debrecen2.hpc.niif.hu
If a non-default key is used, it must be specified with the -i KEY option (SSH and SCP commands).
Copying files with SCP
Download from the HOME directory and upload to the HOME directory:
Up: scp FILE USER@login.debrecen2.hpc.niif.hu: FILE
Down: scp USER@login.debrecen2.hpc.niif.hu: FILE FILE
Data synchronization
Larger files / directory structures shall be synchronized using the following commands
Up: rsync -a -e ssh DIRECTORY USER@login.debrecen2.hpc.niif.hu:/home/USER
Down: rsync -a -e ssh USER@login.debrecen2.hpc.niif.hu:/home/USER/DIRECTORY
The --delete option must be specified to synchronize deleted files.
User interface
short form of CWD
|
DEBRECEN2[login] ~ (0)$
| | |
HPC station | |
short machine name |
exit code of the previous command
Module environment
The list of available modules is obtained with the following command:
module avail
the list of already loaded modules:
module list
You can load an application with the following command:
module load APP
The environment variables set by KIFÜ are listed by the nce command.
Data sharing for project members
setfacl -m u:OTHER:rx $HOME
To make a specific directory (DIRECTORY) writable:
setfacl -m u:OTHER:rxw $HOME/DIRECTORY
You can list extended rights with the following command:
getfacl $HOME/DIRECTORY
Using a shared home directory
The common file system that is available for the login nodes of the supercomputers is accessible under the following path:
/mnt/fhgfs/home/$USER
Backups could be made into the shared directory with the following command:
rsync -avuP --delete $HOME/DIRECTORY /mnt/fhgfs/home/$USER
Compiling applications
Users are encouraged to try compiling needed applications in their own home directory first. If it fails for some reason, then the next step is to ask the Hungarian supercomputer users because there is a good chance that others have already run into the same problem. They can be reached at: hpc-forum at listserv.niif.hu
. You can subscribe to this mailing list her. You should also check the archive when looking into the issue. KIFÜ HPC support has extremely limited capacity to handle individual compiling requests but still you may contact hpc-support at niif.hu
with your problem. In the latter case please be patient for a few days while waiting for responses.
Using the SLURM scheduler
The supercomputer has a CPU hour (machine time) based schedule. The following command provides information about the status of the user's Slurm projects (Account):
sbalance
The second column (Usage) shows the machine time spent by each user, and the fourth column shows the total machine time of the account. The last two columns provide information about the maximum (Account Limit) and available machine time.
Scheduler Account Balance
---------- ----------- + ---------------- ----------- + ------------- -----------
User Usage | Account Usage | Account Limit Available (CPU hrs)
---------- ----------- + ---------------- ----------- + ------------- -----------
bob * 7 | foobar 7 | 1,000 993
alice 0 | foobar 7 | 1,000 993
Estimating CPU time
It is advisable to estimate the wall clock time before large-scale (production) runs. To do this, use the following command:
sestimate -N NODES -t WALLTIME
where NODES
is the number of nodes to be reserved and WALLTIME
is the maximum run time.
'''
It is important to specify the wall clock time you want to reserve as accurately as possible, as the scheduler also ranks the jobs waiting to be run based on this. It is generally true that the shorter job will take place sooner. It is advisable to check the actual run time with the sacct
command afterwards.'''
Status information
The squeue
and the sinfo
command provide information about the general state of the cluster. Each job submitted is assigned a unique identification number (JOBID). Knowing this, we can ask for more information. Characteristics of the submitted or already running job:
scontrol show job JOBID
Each job is also put into a so-called accounting database. From this you can retrieve the characteristics of the jobs you have run and the statistics of resource usage. You can view detailed statistics with the following command:
sacct -l -j JOBID
The following command provides information about the memory used:
smemory JOBID
The next one shows disk usage:
sdisk JOBID
SLURM warnings
Resources / AssociationResourceLimit - Waiting for a resource
AssociationJobLimit / QOSJobLimit - Not enough CPU time or maximum CPU number is reserved
Priority - Waiting due to low priority
In the latter case, the time to be reserved by the job must be reduced. Jobs for a given project can run on up to 512 CPUs at a given time.
Checking licenses
Az elérhető és éppen használt licenszekről a következő parancs ad információt:
slicenses
Checking maintenance
In the maintenance time window, the scheduler does not start new jobs, but jobs could still be submitted. The following command provides information on maintenance dates:
sreservations
Aggregate consumption
You can retrieve the CPU minutes consumed up to one month ago with the following command:
susage
Total consumption
If you want to know how much CPU time you have been using for a certain period, you can query it with this command:
sreport -t Hours Cluster AccountUtilizationByUser Accounts=ACCOUNT Start=2015-01-01
Submitting jobs
It is possible to run applications on supercomputers in batch mode. This means that for each run, a job script must be created that includes a description of the resources required and the commands required to run. Scheduler parameters (resource requirements) must be specified with the #SBATCH
directive.
Mandatory parameters
The following parameters must be specified in each case:
#!/bin/bash
#SBATCH -A ACCOUNT
#SBATCH --job-name=NAME
#SBATCH --time=TIME
where ACCOUNT
is the name of the account to be charged (your available accounts are indicated by the sbalance command), NAME
is the short name of the job, and TIME
is the maximum wall clock time (DD-HH:MM:SS).
The following time formats can be used:
"minutes", "minutes:seconds", "hours:minutes:seconds", "days-hours", "days-hours:minutes" and "days-hours:minutes:seconds".
Reservation of GPUs
GPUs are reserved using the following directive:
#SBATCH --gres=gpu:N
N
specifies the number of GPUs / node, which can be 1, 2, and a maximum of 3.
Interactive use
You can submit short interactive jobs with the 'srun' command, e.g.
srun -l -n 1 -t TIME --gres=gpu:1 -A ACCOUNT APP
Submitting batch jobs
To submit jobs use the following command:
sbatch slurm.sh
On successful submission you get the following output:
Submitted batch job JOBID
ahol a JOBID
a feladat egyedi azonosítószáma.
The following command stops the job:
scancel JOBID
Non-restarting jobs
For non-restarting jobs, the following directive should be used:
#SBATCH --no-requeue
Partitions
There are two non-overlapping queues (partitions) on the supercomputer: the prod-gpu-k40
queue and the prod-gpu-k20
queue. Both are for production purposes, the first featuring CN machines with Nvidia K40x GPUs and the second with Nvidia K20x GPUs. The default queue is prod-gpu-k20
. The prod-gpu-k40 partition can be selected with the following directive:
#SBATCH --partition=prod-gpu-k40
Quality of Service (QoS)
The default quality of the service is normal
, i.e. it cannot be interrupted.
High priority
High-priority jobs can run for up to 24 hours and are charged for twice the time in return for prioritizing these jobs.
#SBATCH --qos=fast
Low priority
It is also possible to post low-priority jobs. Such jobs can be interrupted at any time by any normal priority job, in exchange for being charged for only half the machine time spent. Interrupted jobs are automatically rescheduled. Only submit jobs with low priority that can withstand random interruptions and save their status regularly (checkpoint) so that they could be quickly restarted.
#SBATCH --qos=lowpri
Memory allocation
By default, 1 CPU core is assigned 1000 MB of memory but more can be requested with the following directive:
#SBATCH --mem-per-cpu=MEMORY
where MEMORY
is specified in MB. The maximum memory / core can be 7800 MB.
Email notification
Send mail when job status changes (start, stop, error):
#SBATCH --mail-type=ALL
#SBATCH --mail-user=EMAIL
where EMAIL
is the email address to be notified.
Arrayjobs
Arrayjobs are needed when a single threaded (serial) application is to be run in many instances (with different parameters) at once. For instances, the scheduler stores the unique identifier in the SLURM_ARRAY_TASK_ID
environment variable. By querying this, the threads of the array job can be separated. The outputs of the threads are written to the slurm-SLURM_ARRAY_JOB_ID-SLURM_ARRAY_TASK_ID.out
files. The scheduler performs the upload according to a tight pack. You may want to select the number of threads as a multiple of the number of processors in this case too. More information
#!/bin/bash
#SBATCH -A ACCOUNT
#SBATCH --job-name=array
#SBATCH --time=24:00:00
#SBATCH --array=1-96
srun envtest.sh
OpenMPI jobs
For MPI jobs, you must also specify the number of MPI processes starting on each node (#SBATCH --ntasks-per-node=
). In the most common case this is the number of CPU cores of a single node. The parallel program must be started with the mpirun
command.
#!/bin/bash
#SBATCH -A ACCOUNT
#SBATCH --job-name=mpi
#SBATCH -N 2
#SBATCH --ntasks-per-node=8
#SBATCH --time=12:00:00
mpirun --report-pid ${TMPDIR}/mpirun.pid PROGRAM
OpenMPI FAQ: http://www.open-mpi.org/faq
OpenMP (OMP) jobs
A maximum of 1 node can be reserved for OpenMP parallel applications. The number of OMP threads must be specified with the OMP_NUM_THREADS
environment variable. The variable must either be set before the application (see example) or exported before the start command:
export OMP_NUM_THREADS=8
In the following example, we have assigned 8 CPU cores to a task, the 8 CPU cores must be on one node. The number of CPU cores is included in the SLURM_CPUS_PER_TASK
variable, and it also sets the number of OMP threads.
User Alice launches an 8-thread OMP application at the expense of the foobar account for a maximum of 6 hours.
#!/bin/bash
#SBATCH -A foobar
#SBATCH --job-name=omp
#SBATCH --time=06:00:00
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=8
OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK ./a.out
Hybrid MPI-OMP jobs
We speak of a hybrid MPI-OMP mode when the parallel application uses both MPI and OMP. It is worth noting that MKL calls of programs linked with Intel MKL are OpenMP-capable. In general, the following distribution is recommended: the number of MPI processes from 1 to the number of CPU sockets in one node, the OMP threads to be the total number of CPU core numbers in one node, or half, or quarter (as appropriate). For the job script the parameters of the above two modes must be combined.
In the following example, we start 2 nodes and 1-1 task per node with 10 threads per task. User Alice submitted a hybrid job to 2 nodes for 8 hours at the expense of the foobar account. Only 1 MPI process runs on one node at a time, which uses 8 OMP threads per node. The 2 machines run a total of 2 MPI processes and 2 x 8 OMP threads.
#!/bin/bash
#SBATCH -A foobar
#SBATCH --job-name=mpiomp
#SBATCH --time=08:00:00
#SBATCH -N 2
#SBATCH --ntasks=2
#SBATCH --ntasks-per-node=1
#SBATCH --cpus-per-task=8
#SBATCH -o slurm.out
export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK
mpirun ./a.out
Maple Grid jobs
Maple can be run on 1 node - like OMP tasks. You must also load the maple module to use it. Maple works in client-server mode so you must also start the grid server (${MAPLE}/toolbox/Grid/bin/startserver
) before running the Maple job. This application requires a license, which must be specified in the job script (#SBATCH --licenses=maplegrid:1
). The Maple job must be started with the ${MAPLE}/toolbox/Grid/bin/joblauncher
command.
User Alice starts Maple Grid for 6 hours from the foobar account:
#!/bin/bash
#SBATCH -A foobar
#SBATCH --job-name=maple
#SBATCH -N 1
#SBATCH --ntasks-per-node=16
#SBATCH --time=06:00:00
#SBATCH -o slurm.out
#SBATCH --licenses=maplegrid:1
module load maple
${MAPLE}/toolbox/Grid/bin/startserver
${MAPLE}/toolbox/Grid/bin/joblauncher ${MAPLE}/toolbox/Grid/samples/Simple.mpl
HPC
A szuperszámítógépekről
A Kormányzati Informatikai Fejlesztési Ügynökség (KIFÜ) szuperszámítógép szolgáltatása tudományos számítási feladatok futtatására, valamint tudományos célú adattárolásra szolgál. A jelenleg integrált szuperszámítógép-rendszer komponensei négy helyszínen találhatók:
- Debreceni Egyetem
- KIFÜ központ
- Pécsi Tudományegyetem
- Szegedi Tudományegyetem
- Miskolci Egyetem
A tudományos számítási feladatok különböző típusainak minél szélesebb körű lefedettsége érdekében az egyes helyszíneken különböző felépítésű gépek találhatók: két helyszínen ccNUMA, három helyszínen pedig "fat-node" fürtözött megoldás. Az alrendszereket a KIFÜ nagy sávszélességű, alacsony késleltetésű HBONE+ adathálózatán keresztül, ARC grid köztesréteg, valamint harmonizált felhasználói azonosítás segítségével integráljuk egységes elvek mentén elérhető számítási egységgé. Az erőforrás jelenleg Magyarország legnagyobb tudományos számítás céljára felhasználható erőforrása, amely összesen 50 billió lebegőpontos művelet elvégzését teszi lehetővé másodpercenként. A szuperszámítógép-rendszert a KIFÜ üzemelteti és fejleszti. A rendszerhez regisztrációt követően, minden olyan személy vagy kutatócsoport hozzáférhet, amely tagintézményi szerződéses kapcsolatban áll a KIFÜ-vel. A gépen megtalálhatók és futtathatók a legkorszerűbb fejlesztőeszközök és tudományos számításra szolgáló alkalmazások, valamint, az NIIF Program adatközpontban elhelyezett alrendszer kivételével, valamennyi alrendszer kiegészül a számítási feladatok eredményeit megjelenítő vizualizációs eszközökkel.
Szuperszámítógépeink összehasonlítása
Helyszín | Budapest | Budapest2 | Szeged | Debrecen | Debrecen2-GPU (Leo) | Debrecen3-Phi (Apollo) | Pécs | Miskolc |
---|---|---|---|---|---|---|---|---|
Típus | HP CP4000SL | HP SL250s | HP CP4000BL | SGI ICE8400EX | HP SL250s | HP Apollo 8000 | SGI UV 1000 | SGI UV 2000 |
CPU-k / node | 2 | 2 | 4 | 2 | 2 | 2 | 192 | 44 |
Core-ok / CPU | 12 | 10 | 12 | 6 | 8 | 12 | 6 | 8 |
Memória / node | 66 GB | 63 GB | 132 GB | 47 GB | 125 GB | 125 GB | 6 TB | 1.4 TB |
Memória / core | 2.6 GB | 3 GB | 2.6 GB | 2.6 GB | 7 GB | 5 GB | 5 GB | 3.75 GB |
CPU | AMD Opteron 6174 @ 2.2GHz | Intel Xeon E5-2680 v2 @ 2.80GHz | AMD Opteron 6174 @ 2.2GHz | Intel Xeon X5680 @ 3.33 GHz | Intel Xeon E5-2650 v2 @ 2.60GHz | Intel Xeon E5-2670 v3 @ 2.30GHz | Intel Xeon X7542 @ 2.66 GHz | Intel Xeon E5-4627 v2 @ 3.33 GHz |
GPU | - | - | 2 * 6 Nvidia M2070 | - | 68 * 3 Nvidia K20x + 16 * 3 Nvidia K40x | - | - | - |
Intel Xeon Phi (KNC) | - | 14 * 2 * Intel(R) Xeon Phi(TM) MIC SE10/7120 | - | - | - | 45 * 2 * Intel(R) Xeon Phi(TM) MIC SE10/7120 | - | - |
Linpack teljesítmény (Rmax) | 5 Tflops | 27 Tflops | 20 Tflops | 18 Tlops | 254 Tflops | ~106 Tflops | 10 Tflops | 8 Tflops |
Compute node-ok száma | 32 | 14 | 50 | 128 | 84 | 45 | 1 | 1 |
Dedikált storage | 50 TB | 500 TB | 250 TB | 500 TB | 585 TB (Phi-vel közös) | 585 TB (GPU-val közös) | 500 TB | 240 TB |
Interconnect | IB QDR | IB NB FDR | IB QDR | IB QDR | IB NB FDR | IB NB FDR | Numalink 5 | Numalink 6 |
Scheduler | SLURM | SLURM | SLURM | SLURM | SLURM | SLURM | SLURM | SLURM |
MPI | OpenMPI (ompi) | IntelMPI (impi) | OpenMPI (ompi) | SGI MPT (mpt) | OpenMPI (ompi) | OpenMPI (ompi) | SGI MPT (mpt) | SGI MPT (mpt) |
További információ
A KIFÜ HPC-k dokumentációja
Kapcsolódó oldalak
- HPC portál: projekt és témaszámok kezelése, leállások, statisztikák
- A szuperszámítógépek használata
- GY.I.K
- Telepített HPC Szoftverek
- Az NIIF Szuperszámítógép Felhasználói Szabályzata
- Elérhető fájlrendszerek a HPC központokban
- HPC vizualizációs infrastruktúra elérése
Saját HPC oktató tartalmaink
- HPC oktató videók
- HPC tutorial (NWS 2015) anyagai
- GPU programozás workshop (videotorium)
- Xeon Phi kártyák használata és alkamazások optimalizációja
Angol nyelvű tréningek, videók, anyagok
HPC_felhasznaloi_alapelvek
A KIFÜ Szuperszámítógép Felhasználói Szabályzata
Az alábbi dokumentum által rögzített szabályok a Kormányzati Informatikai Fejlesztési Ügynökség (KIFÜ) Szuperszámítógép Központ összes felhasználója számára kötelezően betartandók. A szabályok megszegését a KIFÜ szankcionálja. Noha a szabályok számos tiltást is tartalmaznak, ezek célja természetesen nem a munka megnehezítése vagy kényelmetlenné tétele. Az üzemeltetők szándéka az, hogy ezt a nagy értékű erőforrást minél biztonságosabban és minél hatékonyabban, minél több felhasználó használhassa. Ezért van szükség az olykor szigorú rendszabályok maradéktalan betartására, melyek egyben a felhasználók érdekeit is szolgálják.
1. A témaszám
- A témaszámok egyediek, személyre szólóak, át nem ruházhatók, kölcsön nem adhatók még ideiglenesen sem.
- A témaszám tulajdonosa a témaszámot kizárólag az igényléskor bejelentett projekthez és feladatokhoz használhatja.
- A témaszám átvételével a felhasználó deklarálja, hogy megismerte, elfogadja és magára nézve kötelezőnek tartja a szuperszámítógép Felhasználói Szabályzatát.
2. Biztonság
- Minden körülmények között törekedni kell a rendszer és adatainak maximális biztonságára.
- A rendszerben észlelt bármilyen biztonsági probléma, hiba vagy a témaszám illegális használatára, a rendszerbe való betörésre utaló jelek esetén haladéktalanul értesíteni kell a KIFÜ-t.
- A felhasználó számítógépe és a szuperszámítógép között kizárólag biztonságos (titkosított adatátvitelt használó)protokollok segítségével szabad kapcsolatot teremteni. Mind az alfanumerikus illetve a grafikus felületek továbbításához, a file transzferhez az ssh (secure shell) protokollt kell használni.
- Tilos a szuperszámítógépet elektronikus levelezésre, Webböngészésre használni, valamint tilos rajta hálózati szolgáltatásokat üzemeltetni.
- A standard, telepített alkalmazásokon kívül csak a Kormányzati Informatikai Fejlesztési Ügynökség (KIFÜ) külön engedélyével futtathatók olyan szoftverek amelyek önálló hálózati kommunikációt végeznek.
3. A szuperszámítógép használata
- A szuperszámítógépet csak érvényes témaszám birtokában, a témaszám igénylésekor megjelölt feladatokra lehet használni a kapott kvóták keretein belül.
- A szuperszámítógép erőforrásait takarékosan kell használni, kerülve a szükségesnél több kapacitás használatát.
- Tilos az erőforrásokat a kapott kvóták keretein túl igénybe venni, vagy ezt megkísérelni.
- Tilos az operációs rendszer védelmi rendszerének a feltörését megkísérelni.
- Tilos a szuperszámítógépre nem jogtiszta szoftvereket telepíteni.
- Tilos a szuperszámítógépet bármilyen törvénybe ütköző cselekedetre használni.
- Tilos a szuperszámítógéppel olyan tevékenységet folytatni, amely ellentétes a KIFÜ NIIF Program használatának szabályzatával. (KIFÜ AUP)
- A felhasználó a Felhasználói Szabályzat rendelkezéseinek betartásán túlmenően mindenkor köteles elfogadni és követni a szuperszámítógépet üzemeltető személyzet esetleges utasításait.
- A felhasználó kizárólagosan felelős a témaszámán folytatott mindennemű tevékenységért és a rendelkezésére bocsátott erőforrásokért erkölcsi, anyagi és jogi értelemben egyaránt.
4. Az üzemeltető jogai
- A szuperszámítógép felhasználója tudomásul veszi, hogy a felhasználás tényére, a projektre és annak eredményeire a KIFÜ nyilvánosan is hivatkozhat.
- Az üzemeltetőnek jogában áll a rendszer karbantartása illetve hibaelhárítás során a felhasználó katalógusaiba és file-jaiba betekinteni, noha azok tartalmát harmadik féllel nem közölheti (kivéve, ha a Felhasználói Szabályzat megsértésének alapos gyanúja merül fel a felhasználóval szemben).
- A KIFÜ-nek jogában áll a felhasználót szankcionálni abban az esetben ha alapos gyanú merül fel arra vonatkozólag, hogy a felhasználó a Felhasználói Szabályzat rendelkezéseit megsértette. A szankcionálás állhat a hozzáférés korlátozásából vagy felfüggesztéséből, de súlyosabb esetben jogi felelősségre vonás is kezdeményezhető.
5. Hivatkozási és beszámolási kötelezettség
- A szuperszámítógép alkalmazásával elért tudományos eredmények, tapasztalatok hazai és nemzetközi publikációiban meg kell említeni a KIFÜ infrastruktúra alkalmazásának tényét.
- A szuperszámítógépet felhasználó projektek státuszáról, előrehaladásáról, elért eredményeiről évente legalább egyszer,(illetve a projekt befejeződésekor, a témaszám megszűnésekor, vagy a KIFÜ külön kérésére bármikor) rövid írásos összegzést kell küldeni a KIFÜ-nek melyben többek között meg kell adni a projekttel kapcsolatban megjelent publikációk jegyzékét és elérhetőségét is. Az éves beszámoló megküldésének határideje november 30.
HPC_konyvtarak
Elérhető fájlrendszerek a HPC központokban
Home Minden felhasználó rendelkezik egy saját könyvtárral a /home filerendszeren (home könyvtár). Ez a könyvtár (/home/userid)szolgál a programok, forráskódok és kisebb mennyiségű adat tárolására. A home-könyvtár hálózati fájlrendszeren keresztül van megosztva a login node és a számítást végző node(ok) között.
A home-könyvtárat rendszeresen mentjük, ezért lényeges, hogy az alábbi adatokat NE tároljuk benne:
- számítások köztes eredményei
- gyorsan változó, nagy mennyiségű adat
- könnyen reprodukálható, nagy mennyiségű input adat
- szükségtelen adatok (régi projektek lefordított objektumai, core dump-ok, stb)
Scratch
Minden felhasználó rendelkezik egy saját könyvtárral a /scratch fájlrendszeren (scratch könyvtár). Ez a könyvtár (/scratch/userid) szolgál az ideiglenes vagy köztes számítási eredmények valamint nagyobb mennyiségű adat tárolására. A scratch könyvtár hálózati fájlrendszeren keresztül van megosztva a login node és a számítást végző node(ok) között.
A scratch-könyvtárat nem mentjük, és - abban az esetben, ha a fájlrendszer betelítődése fenyeget - a 30 napnál régebbi fájlokat töröljük.
**Közös home könyvtár**Debrecen2_GPU_klaszter
Klaszter | Debrecen2 (Leo) |
---|---|
Típus | HP SL250s |
core / node | 8 × 2 Xeon E5-2650v2 2.60GHz |
GPU / node | 68 * 3 Nvidia K20x + 16 * 3 Nvidia K40x |
Compute node-ok | 84 db |
Max Walltime | 7-00:00:00 |
Max core-ok / projekt | 336 |
Max mem / core | 7000 MB |
CPU idő kérés
!!! tip
A CPU idő igénylésekor egy olyan rövid indoklást várunk a HPC projekt vezetőktől, amiből kiderül, hogy a futtatandó alkalmazás képes GPU-t használni (ez alól kivétel, ha a felhasználás célja a gépen elérhető licenszelt szoftver használata, amennyiben az nem képes GPU-t használni (pl. Gaussian, Maple)). Erre azért van szükség, mert az erőforrás teljesítményének nagyobbik része GPU gyorsításból származik, egy gyorsítás nélküli program a CPU-kat lefoglalja, korlátozva ezzel a GPU-k használatát, ami kihasználatlansághoz vezet. Az NVidia [közzétett egy listát](http://www.nvidia.com/object/gpu-applications.html) arról, hogy melyik alkalmazás rendelkezik jelenleg hivatalosan NVidia GPU támogatással, de természetesen egyéb, GPU-t használó program is nagy valószínűséggel jól fut a gépen.
* A GPU programozás iránt érdeklődőknek tartottunk egy workshopot, amelynek video anyagai elérhetőek itt: [GPU programozás workshop (videotorium)](http://videotorium.hu/hu/events/details/1864,GPU_programozas_workshop)
Belépés
ssh USER@login.debrecen2.hpc.niif.hu
Nem alapértelmezett kulcs használata esetén a -i KULCS
kapcsolóval megadása szükséges (SSH és SCP parancsok).
Fájlok másolása SCP-vel
Letöltés a HOME könyvtárból és feltöltés a HOME könyvtárba:
Fel: scp FILE USER@login.debrecen2.hpc.niif.hu:FILE
Le : scp USER@login.debrecen2.hpc.niif.hu:FILE FILE
Adatszinkronizáció
Nagyobb fájlok ill. könyvtárstruktúrák szinkronizálásához a következő parancsokat kell használni
Fel: rsync -a -e ssh DIRECTORY USER@login.debrecen2.hpc.niif.hu:/home/USER
Le : rsync -a -e ssh USER@login.debrecen2.hpc.niif.hu:/home/USER/DIRECTORY
A törölt fájlok szinkronizálásához a --delete
opciót kell megadni.
Felhasználói felület
rövid CWD
|
DEBRECEN2[login] ~ (0)$
| | |
HPC állomás | |
rövid gép név |
előző parancs exit kódja
Modul környezet
Az elérhető modulok listáját a következő paranccsal kapjuk meg:
module avail
a már betöltött modulok listáját:
module list
Alkalmazást a következő paranccsal tölthetünk be:
module load APP
A NIIF által beállított környezeti változókat nce
parancs listázza ki.
Adatok megosztása projekt tagok számára
Fájlok ill. könyvtárak megosztásához ACL-eket kell beállítani. A HOME könyvtárat más felhasználó (OTHER) számára olvashatóvá, így tehetjük
setfacl -m u:OTHER:rx $HOME
Addott könyvtárat (DIRECTORY) írahtóvá:
setfacl -m u:OTHER:rxw $HOME/DIRECTORY
A kiterjesztett jogokat a következő paranccsal kérhetjük le:
getfacl $HOME/DIRECTORY
Közös home könyvtár használata
A szuperszámítógépek login gépeit összekötő közös fájlrendszer a következő könyvtár alatt található:
/mnt/fhgfs/home/$USER
Biztonsági mentést a közös könyvtárba a következő paranccsal tudunk végezni:
rsync -avuP --delete $HOME/DIRECTORY /mnt/fhgfs/home/$USER
Alkalmazások lefordítása
Mindenkitől azt kérjük, hogy először próbálja meg saját maga lefordítani az alkalmazását. Ha ez valamilyen oknál fogva mégsem sikerülne, akkor következő lépésként a magyarországi szuperszámítógép felhasználóktól érdemes kérdezni, mert nagy esély van rá hogy mások is belefutottak ugyanabba a problémába. Ezen a címen lehet őket elérni: hpc-forum kukac listserv.niif.hu
. Feliratkozni itt lehet erre a levelezőlistára. Az archívumban is érdemes utánanézni a kérdésnek. Az NIIF HPC support csak igen korlátozottan képes egyéni fordítási kérésekkel foglalkozni, de problémával felkeresheti a hpc-support kukac niif.hu
címet. Az utóbbi esetben pár napos türelmüket mindenképp kérjük válaszunkig.
SLURM ütemező használata
A szuperszámítógépen CPU óra (gépidő) alapú ütemezés működik. A felhasználóhoz tartozó Slurm projektek (Account) állapotáról a következő parancs ad információt:
sbalance
A második oszlopban (Usage) az egyes felhasználók elhasznált gépideje, a negyedik oszlopban pedig a számla összesített gépideje látható. Az utolsó két oszlop a maximális (Account Limit) és a még elérhető (Available) gépidőről ad tájékoztatást.
Scheduler Account Balance
---------- ----------- + ---------------- ----------- + ------------- -----------
User Usage | Account Usage | Account Limit Available (CPU hrs)
---------- ----------- + ---------------- ----------- + ------------- -----------
bob * 7 | foobar 7 | 1,000 993
alice 0 | foobar 7 | 1,000 993
A gépidő becslése
Nagyüzemi (production) futtatások előtt gépidőbecslést érdemes végezni. Ehhez a következő parancs használható:
sestimate -N NODES -t WALLTIME
ahol a NODES
a lefoglalni kívánt node-ok száma, a WALLTIME
pedig a futás maximális ideje.
Fontos, hogy a lefoglalni kívánt gépidőt a lehető legpontosabban adjuk meg, mivel az ütemező ez alapján is rangsorolja a futtatásra váró feladatokat. Általában igaz, hogy a rövidebb job hamarabb sorra kerül. Érdemes minden futás idejét utólag az sacct
paranccsal is ellenőrizni.
Állapotinformációk
Az ütemezőben lévő jobokról az squeue
, a klaszter általános állapotáról az sinfo
parancs ad tájékoztatást. Minden beküldött jobhoz egy egyedi azonosítószám (JOBID) rendelődik. Ennek ismeretében további információkat kérhetünk. Feladott vagy már futó job jellemzői:
scontrol show job JOBID
Minden job egy ún. számlázási adatbázisba (accounting) is bekerül. Ebből az adatbázisból visszakereshetők a lefuttatott feladatok jellemzői és erőforrás-felhasználás statisztikái. A részletes statisztikát a következő paranccsal tudjuk megnézni:
sacct -l -j JOBID
A felhasznált memóriáról a következő parancs ad tájékoztatást:
smemory JOBID
A lemezhasználatról pedig a
sdisk JOBID
Slurm figyelmeztető üzenetek
Resources/AssociationResourceLimit - Erőforrásra vár
AssociationJobLimit/QOSJobLimit - Nincs elég CPU idő vagy a maximális CPU szám le van foglalva
Piority - Alacsony prioritás miatt várakozik
Az utóbbi esetben, csökkenteni kell a job által lefoglalni kívánt időt. Egy adott projekt részére maximálisan 512 CPU-n futhatnak jobok egy adott időben.
Licenszek ellenőrzése
Az elérhető és éppen használt licenszekről a következő parancs ad információt:
slicenses
Karbantartás ellenőrzése
A karbantartási időablakban az ütemező nem indít új jobokat, de beküldeni lehet. A karbantartások időpontjairól a következő parancs ad tájékoztatást:
sreservations
Összesített felhasználás
Egy hónapra visszamenőleg az elfogyasztott CPU perceket a következő paranccsal kérhetjük le:
susage
Teljes fogyasztás
Ha szeretnénk tájékozódni arról, hogy egy bizony idő óta mennyi a CPU idő felhasználásunk akkor azt ezzel paranccsal tudjuk lekérdezni:
sreport -t Hours Cluster AccountUtilizationByUser Accounts=ACCOUNT Start=2015-01-01
Feladatok futtatása
Alkalmazások futtatása a szupergépeken kötegelt (batch) üzemmódban lehetséges. Ez azt jelenti, hogy minden futtatáshoz egy job szkriptet kell elkészíteni, amely tartalmazza az igényelt erőforrások leírását és a futtatáshoz szükséges parancsokat. Az ütemező paramétereit (erőforrás igények) a #SBATCH
direktívával kell megadni.
Kötelező paraméterek
A következő paramétereket minden esetben meg kell adni:
#!/bin/bash
#SBATCH -A ACCOUNT
#SBATCH --job-name=NAME
#SBATCH --time=TIME
ahol az ACCOUNT
a terhelendő számla neve (elérhető számláinkről az sbalance
parancs ad felvilágosítást), a NAME
a job rövid neve, a TIME
pedig a maximális walltime idő (DD-HH:MM:SS
). A következő időformátumok használhatók:
"minutes", "minutes:seconds", "hours:minutes:seconds", "days-hours", "days-hours:minutes" és "days-hours:minutes:seconds".
GPU-k lefoglalása
A GPU-k lefoglalása a következő direktívával törénik:
#SBATCH --gres=gpu:N
Az N
a GPU-k/node számát adja meg, ami 1, 2 és 3 lehet maximum.
Interaktív használat
Rövid interaktív feladatokat az 'srun' paranccsal tudunk beküldeni, pl.:
srun -l -n 1 -t TIME --gres=gpu:1 -A ACCOUNT APP
Batch job-ok indítása
A jobok feladását a következő parancs végzi:
sbatch slurm.sh
Sikeres feladás esetén a következő kimenetet kapjuk:
Submitted batch job JOBID
ahol a JOBID
a feladat egyedi azonosítószáma.
A feladat leállítását a következő parancs végzi:
scancel JOBID
Nem újrainduló jobok
Nem újrainduló jobokhoz a következő direktívát kell használni:
#SBATCH --no-requeue
Feladat sorok
A szupergépen két, egymást nem átfedő, sor (partíció) áll rendelkezésre, a prod-gpu-k40
sor és a prod-gpu-k20
sor. Mind a kettő éles számolásokra való, az első olyan CN gépeket tartalmaz amikben Nvidia K40x GPU-k, a másodikban pedig Nvidia K20x GPU-k vannak. Az alapértelmezett sor a prod-gpu-k20
. A prod-gpu-k40 partíciót a következő direktívával lehet kiválasztani:
#SBATCH --partition=prod-gpu-k40
A szolgáltatás minősége (QOS)
A szolgáltatást alapértelmezett minősége normal
, azaz nem megszakítható a futás.
Magas prioritás
A magas prioritású jobok maximum 24 óráig futhatnak, és kétszer gyorsabb időelszámolással rendelkeznek, cserébe az ütemező előreveszi ezeket a feladatokat.
#SBATCH --qos=fast
Alacsony prioritás
Lehetőség van alacsony prioritású jobok feladására is. Az ilyen feladatokat bármilyen normál prioritású job bármikor megszakíthatja, cserébe az elhasznált gépidő fele számlázódik csak. A megszakított jobok automatikusan újraütemeződnek. Fontos, hogy olyan feladatokat indítsunk alacsony prioritással, amelyek kibírják a véletlenszerű megszakításokat, rendszeresen elmentik az állapotukat (checkpoint) és ebből gyorsan újra tudnak indulni.
#SBATCH --qos=lowpri
Memória foglalás
Alapértelmezetten 1 CPU core-hoz 1000 MB memória van rendelve, ennél többet a következő direktívával igényelhetünk:
#SBATCH --mem-per-cpu=MEMORY
ahol MEMORY
MB egységben van megadva. A maximális memória/core 7800 MB lehet.
Email értesítés
Levél küldése job állapotának változásakor (elindulás,leállás,hiba):
#SBATCH --mail-type=ALL
#SBATCH --mail-user=EMAIL
ahol az EMAIL
az értesítendő emial cím.
Tömbfeladatok (arrayjob)
Tömbfeladatokra akkor van szükségünk, egy szálon futó (soros) alkalmazást szeretnénk egyszerre sok példányban (más-más adatokkal) futtatni. A példányok számára az ütemező a SLURM_ARRAY_TASK_ID
környezeti változóban tárolja az egyedi azonosítót. Ennek lekérdezésével lehet az arrayjob szálait elkülöníteni. A szálak kimenetei a slurm-SLURM_ARRAY_JOB_ID-SLURM_ARRAY_TASK_ID.out
fájlokba íródnak. Az ütemező a feltöltést szoros pakolás szerint végzi. Ebben az esetben is érdemes a processzorszám többszörösének választani a szálak számát. Bővebb ismertető
#!/bin/bash
#SBATCH -A ACCOUNT
#SBATCH --job-name=array
#SBATCH --time=24:00:00
#SBATCH --array=1-96
srun envtest.sh
OpenMPI feladatok
MPI feladatok esetén meg kell adnunk az egy node-on elinduló MPI processzek számát is (#SBATCH --ntasks-per-node=
). A leggyakoribb esetben ez az egy node-ban található CPU core-ok száma. A párhuzamos programot az mpirun
paranccsal kell indítani.
#!/bin/bash
#SBATCH -A ACCOUNT
#SBATCH --job-name=mpi
#SBATCH -N 2
#SBATCH --ntasks-per-node=8
#SBATCH --time=12:00:00
mpirun --report-pid ${TMPDIR}/mpirun.pid PROGRAM
OpenMPI FAQ: http://www.open-mpi.org/faq
OpenMP (OMP) feladatok
OpenMP párhuzamos alkalmazásokhoz maximum 1 node-ot lehet lefoglalni. Az OMP szálák számát az OMP_NUM_THREADS
környezeti változóval kell megadni. A változót vagy az alkamazás elé kell írni (ld. példa), vagy exportálni kell az indító parancs előtt:
export OMP_NUM_THREADS=8
A következő példában egy taskhoz 8 CPU core-t rendeltunk, a 8 CPU core-nak egy node-on kell lennie. A CPU core-ok számát a SLURM_CPUS_PER_TASK
változó tartalmazza, és ez állítja be az OMP szálak számát is.
Alice felhasználó a foobar számla terhére, maximum 6 órára indít el egy 8 szálas OMP alkalmazást.
#!/bin/bash
#SBATCH -A foobar
#SBATCH --job-name=omp
#SBATCH --time=06:00:00
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=8
OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK ./a.out
Hibrid MPI-OMP feladatok
Hibrid MPI-OMP módról akkor beszélünk, ha a párhuzamos alkalmazás MPI-t és OMP-t is használ. Érdemes tudni, hogy az Intel MKL-el linkelt programok MKL hívásai OpenMP képesek. Általában a következő elosztás javasolt: az MPI processzek száma 1-től az egy node-ban található CPU foglalatok száma, az OMP szálak ennek megfelelően az egy node-ban található összes CPU core szám vagy annak fele, negyede (értelem szerűen). A jobszkipthez a fenti két mód paramétereit kombinálni kell.
A következő példában 2 node-ot, és node-onként 1-1 taskot indítunk taskonként 10 szállal. Alice felhasználó a foobar számla terhére, 8 órára, 2 node-ra küldött be egy hibrid jobot. Egy node-on egyszerre csak 1 db MPI processz fut ami node-onként 8 OMP szálat használ. A 2 gépen összesen 2 MPI proceszz és 2 x 8 OMP szál fut.
#!/bin/bash
#SBATCH -A foobar
#SBATCH --job-name=mpiomp
#SBATCH --time=08:00:00
#SBATCH -N 2
#SBATCH --ntasks=2
#SBATCH --ntasks-per-node=1
#SBATCH --cpus-per-task=8
#SBATCH -o slurm.out
export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK
mpirun ./a.out
Maple Grid feladatok
Maple-t az OMP feladatokhoz hasonlóan 1 node-on lehet futtatni. Használatához be kell tölteni a maple modult is. A Maple kliens-szerver üzemmódban működik ezért a Maple feladat futtatása előtt szükség van a grid szerver elindítására is (${MAPLE}/toolbox/Grid/bin/startserver
). Ez az alkalmazás licensz köteles, amit a jobszkriptben meg kell adni (#SBATCH --licenses=maplegrid:1
). A Maple feladat indátását a ${MAPLE}/toolbox/Grid/bin/joblauncher
paranccsal kell elvégezni.
Alice felhasználó a foobar számla terhére, 6 órára indítja el a Maple Grid alkalmazást:
#!/bin/bash
#SBATCH -A foobar
#SBATCH --job-name=maple
#SBATCH -N 1
#SBATCH --ntasks-per-node=16
#SBATCH --time=06:00:00
#SBATCH -o slurm.out
#SBATCH --licenses=maplegrid:1
module load maple
${MAPLE}/toolbox/Grid/bin/startserver
${MAPLE}/toolbox/Grid/bin/joblauncher ${MAPLE}/toolbox/Grid/samples/Simple.mpl