HPC

Auto-generated book for HPC

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:

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ő:

  1. 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.
  2. 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

Back to the Leo Wiki page

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:

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:

http://slurm.schedmd.com

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?!

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

Xeon-phi-family-rwd.png.rendition.intel.web.720.405.png

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:

  1. Alkalmazás megírása. például hello.cc

  2. Alkalmazás fordítása

    icpc -o hello-MIC -mmic hello.cc
    
  3. A tool futásához szükséges library-k megadása

    export SINK_LD_LIBRARY_PATH=/opt/intel/composerxe-<verzió>/compiler/lib/mic
    
  4. 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. Offload modell 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. Offload modell és OpenMP 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. MPI elosztás valamint Offload modell és OpenMP

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:

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:

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.

SIMD

Főbb támogatott műveletek:

Használata: simd fordítási direktívával lehetséges Például:

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.

Vektor regularizáció

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:

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.

#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;
	}
}
#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

Back to the Leo Wiki page

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

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:

  1. 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
  2. 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
  3. 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
  4. 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.
  5. 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

Bemutató előadás a portálról

Hozzáférés igénylése

Bejelentkezés eduID-vel

Virtuális befogadóintézmény (VHO) tagság igénylése

Projekt igénylés

A portál bemutatása

A portál itt érhető el:

https://portal.hpc.niif.hu/

Személyes adatok menü

Személyes adatok

SSH kulcs

hpc_portal_user_data.jpg

X.509 tanúsítványok

hpc_portal_x509_cert_generation.jpg

Felhasználási lehetőségek a szuperszámítógépek esetén: GSI-SSH, GridFTP, ARC köztesréteg

Hírek

hpc_portal_news.jpg

Projekt

Projekt információk

hpc_portal_project_info.jpg

Projekt felhasználók

hpc_portal_project_users.jpg

Projekt statisztikák

hpc_portal_project_statistics.jpg

Szolgáltatások állapota

HPC szolgáltatások állapota

hpc_portal_service_status.jpg

Események

Események szűrése

hpc_portal_service_events.jpg

Hibabejelentés

Hibajegy nyitása

hpc_portal_error_report.jpg

Korábbi projektek migrációja

Grid Portál

Bemutató a Videotoriumon

hpc_portal_grid_portal.jpg

Egyéb információk

Adatkezelési szabályzat

Adatkezelő neve és elérhetősége

Szolgáltatás megnevezése

Az adatkezelés célja

Az adatkezelés jogalapja

Kezelt személyes adatok köre

Föderációs azonosítás során megkapott személyes adatok
A Szolgáltatás használata során keletkező személyes adatok
Felhasználó által megadott adatok
Naplóbejegyzések

Adatok kiadása harmadik fél számára

Adatbiztonság

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:

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

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.

  1. 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
  2. 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

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.

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]

The following table lists parameters which you can set to optimize the performance of your data transfer:

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

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:

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.hu

roczei@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:

|center

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 |600px|center

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

To share files / directories ACLs must be set. To make the HOME directory readable by another user (OTHER):

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:

alt=A KIFÜ szuperszámítógépei térképen

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

Saját HPC oktató tartalmaink

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

  1. 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.
  2. A témaszám tulajdonosa a témaszámot kizárólag az igényléskor bejelentett projekthez és feladatokhoz használhatja.
  3. 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

  1. Minden körülmények között törekedni kell a rendszer és adatainak maximális biztonságára.
  2. 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.
  3. 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.
  4. 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.
  5. 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

  1. 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.
  2. 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.
  3. Tilos az erőforrásokat a kapott kvóták keretein túl igénybe venni, vagy ezt megkísérelni.
  4. Tilos az operációs rendszer védelmi rendszerének a feltörését megkísérelni.
  5. Tilos a szuperszámítógépre nem jogtiszta szoftvereket telepíteni.
  6. Tilos a szuperszámítógépet bármilyen törvénybe ütköző cselekedetre használni.
  7. 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)
  8. 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.
  9. 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

  1. 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.
  2. 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).
  3. 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

  1. 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.
  2. 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:

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**

Erről itt tájékozódhat

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