Računanje in SLING: Slovensko superračunalniško omrežje v praksi

Kazalo/Content

Potrebščine

Ob predavanju je pričakovano praktično delo. Uporabniki zato potrebujejo računalnik z mrežno povezavo, terminal in ssh ter elektronsko potrdilo.

Postopek za pridobitev trajnega dostopa do Slovenskega nacionalnega superračunalniškega omrežja SLING:

Vloga za elektronsko potrdilo SLING CA:
- Formular: http://signet-ca.ijs.si/CA-formular.pdf
- Prvič se morajo uporabniki tudi overiti z osebnim dokumentom: kje se lahko overim.
- Zahtevek izpolnite (uporabite Mozilla Firefox ali OpenSSL) na: http://signet-ca.ijs.si/pub/

Pretvorba in namestitev elektronskih potrdil:

openssl pkcs12 -in usercert.p12 -clcerts -nokeys -out usercert.pem
openssl pkcs12 -in usercert.p12 -nocerts -out userkey.pem
chmod 400 userkey.pem
chmod 644 usercert.pem
mv userkey.pem ~/.arc/
mv usercert.pem ~/.arc/

Članstvo v virtualni organizaciji:
- Po overjanju je treba preko članstva v virtulani organizaciji dobiti dovoljenje za uporabo.
- gen.vo.sling.si omogoča prost dostop slovenskim upravičencem – stran za prijavo (z nameščenim osebnim potrdilom) je tu: https://voms.sling.si:8443/voms/gen.vo.sling.si
- fri.vo.sling.si omogoča prost dostop slovenskim upravičencem – stran za prijavo (z nameščenim osebnim potrdilom) je tu: https://voms.sling.si:8443/voms/fri.vo.sling.si
Namestitev podpore za overjanje (za uporabo na lastnem računalniku)
- Navodila za namestitev so v ARC Client installation instructions (gl. section 5), splošna navodila: https://wiki.egi.eu/wiki/EGI_IGTF_Release
- Navodila so na spletnih straneh SLING
- Če uporabljate sezname preklicev, jih morate redno obnavljate: namestite paket fetch-crl in poskrbite, da se bo redno zaganjal (cron daily)

Navodila za namestitev in nastavitev odjemalca ARC client installation and VOMS settings (za uporabo na lastnem računalniku)

Navodila: http://www-old.sling.si/sling/uporabniki/uporabniski-vmesniki/

Nastavitev za VOMS za gen.vo.sling.si:

cd ~/.arc
mkdir -p vomsdir/gen.vo.sling.si
cat vomsdir/gen.vo.sling.si/voms.sling.si.lsc 
/C=SI/O=SiGNET/O=SLING/CN=voms.sling.si
/C=SI/O=SiGNET/CN=SiGNET CA

cat vomses/gen.vo.sling.si 
"gen.vo.sling.si" "voms.sling.si" "15001" "/C=SI/O=SiGNET/O=SLING/CN=voms.sling.si" "gen.vo.sling.si"
"fri.vo.sling.si" "voms.sling.si" "15003" "/C=SI/O=SiGNET/O=SLING/CN=voms.sling.si" "fri.vo.sling.si"
"nsc.ijs.si" "voms.sling.si" "15004" "/C=SI/O=SiGNET/O=SLING/CN=voms.sling.si" "nsc.ijs.si"

To je bil kratek opis namestitve programske opreme. Za uporabo prenastavljenih okolij na delavnici to ni potrebno, ker je programska oprema že nameščena.

Za uporabo sistema Singularity so na mnogih sistemih na voljo sistemski paketi, sicer pa je namestitev iz izvorne kode izjemno preprosta: http://singularity.lbl.gov/

Primer naloge na superračunalniku

Primer opisa nalog:

  &
  (executable = /usr/bin/env)
  (jobname = "test")

  (stdout=test.log)
  (join=yes)
  (gmlog=log)
  (memory=1000)

Primer s prenosom datotek:

&
(executable="execution_script.sh")
(stdout="stdout.txt")
(join=yes)
(stdin="stdin.txt")
(inputFiles=
    ("stdin.txt" "http://www.external-url.com/example/stdin.txt")
    ("file1.py" "gsiftp://dcache.arnes.si/data/arnes.si/gen.vo.sling.si/file1.py")
    ("file2.py" "gsiftp://dcache.arnes.si/data/arnes.si/gen.vo.sling.si/file2.py")
)
(outputFiles=
    ("output1.txt" "gsiftp://dcache.arnes.si/data/arnes.si/gen.vo.sling.si/output1.txt")
    ("output2.txt" "gsiftp://dcache.arnes.si/data/arnes.si/gen.vo.sling.si/output2.txt")
)

Primer preproste naloge

Najprej aktivacija: pripravimo posredniško potrdilo:

arcproxy

arcproxy -S fri.vo.sling.si

Preverimo veljavnost:

arcproxy -I
Subject: /C=SI/O=SiGNET/O=SLING/OU=ARCSchoool FRI 2017/CN=Arc School Student 01/CN=1936774291
Issuer: /C=SI/O=SiGNET/O=SLING/OU=ARCSchoool FRI 2017/CN=Arc School Student 01
Identity: /C=SI/O=SiGNET/O=SLING/OU=ARCSchoool FRI 2017/CN=Arc School Student 01
Time left for proxy: 11 hours 59 minutes 51 seconds
Proxy path: /tmp/x509up_u541
Proxy type: X.509 Proxy Certificate Profile RFC compliant impersonation proxy - RFC inheritAll proxy
Proxy key length: 1024
Proxy signature: sha512

Prva naloga

Opis: test.xrsl

&
(executable = /usr/bin/env)(jobname = "test")
(stdout=test.log)
(join=yes)
(gridtime=1000)
(gmlog=log)
(memory=2000)
(runTimeEnv="RESV/FRI")

Boljša naloga

Opis: hellogrid.xrsl

&
(executable=hellogrid.sh)
(wallTime="5 minutes")
(stdout="stdout.txt")
(stderr="stderr.txt")
(runtimeenvironment="RESV/FRI")

Skripta: hellogrid.sh

#!/bin/sh
echo "Hello, grid"

Odpošljemo nalogo…

arcsub -c jost.arnes.si hellogrid.xrsl

Preverimo status in prenesemo rezultate.

Anatomija superračunalniškega omrežja

Skaliranje procesorske moči

Razvoj sodobnih procesorjev in sistemke arhitekture sta nam prinesla večjederne in večprocesorske platforme z neenakovredno arhitekturo dostopa do pomnilnika (NUMA). Vse več pridobivanja moči gre tako v smeri kompleksne paralelizacije računske moči in povečanja učinkovitosti, zato je treba za izkoriščanje kapacitet programe in nalogre prilagoditi tako, da lahko izkoristimo nove arhitekture, in sicer več fizičnih sistemov vzporedno.

Eden od pristopov je vzpostavljanje enotnih sistemov, kjer se več računalnikov, združenih v omrežje, obnaša kot en velik večprocesorski in večjederni sistem. Te rešitve za visoko-učinkovito računanje večinoma niso primerne, saj je zaradi povečanja časovnih zamikov izjemno težko izkoristiti dejanske fizične kapacitete.

Zato superračunalniški sistemi delujejo kot gruče strežnikov, kjer na vsakem posameznem strežniku teče lastne operacijski sistem, vendar so združeni z hitrim nizkolatenčnim omrežjem, enotnim mrežnim diskovnim sistemov, poenotenim sistemom uporabnikov, skupno banko nameščene programske opreme in knjižnic ter sistemom za upravljanje s kapacitetami: sodobnim sistemom vrst.

Upravljanje računskih nalog

Velikih kapacitet takšnega sistema ne bilo mogoče izkoristiti, če bi se uporabniki povezovali neposredno na posamezne računalnike. Namesto tega so gruče opremljene s sistemom vrst, ki sprejme zahtevo za zagon naloge in jo uvrsti v vrsto, potem pa, ko so proste kapacitete, na enem od strežnikov s primernimi kapacitetami zažene nalogo (program) in obvesti uporabnika, ko se naloga izteče.

Takšni sistemi s v uporabi že vse od prvih velikih računalnikov, ko so programi dejansko že tekli na luknjastih karticah, in sicer zato, ker imajo vrsto prednosti pred neposredno uporabo:

load balancing – sistem lahko prilagaja obremenitev posameznih komponent
pravična delitev virov – vrstni red se prilagaja obremenitvi s strani posameznih uporabnikov, sistemi omogočajo kvote, rezervacije ipd.
boljši izkoristek – z ustreznimi podatki je mogoče prilagoditi sistem tako, da kolikor mogoče učinkovito izkorišča opremo, ki je na voljoc.

Ti sistemi so se v okolju mrežnih sistemov grid in superračunalniških centrov intenzivno razvijali. Najpomembnejša problematika v zadnjem času je upravljanje s programsko opremo in velikimi količinami podakotv. Novi uporabniki tako želijo zadnjo različico knjižnic in programov, uporabniki, ki končujejo daljši projekt, pa želijo do konca uporabljati enako okolje, knjižnice in programe. Zato zagotavljamo različne različice v ločenih okoljih z uporabo raznih tehnik, kot so moduli in lahka virtualizacija (“environment modules” in light vitualization ).

Podatki

Računske naloge, ki zahtevajo veliko računsko moč, pogosto potrebujejo ali ustvarjajo velike količine podatkov. Praktični primeri so naloge, ki v 5-10 urah obdelajo 100 do 260 GB na jedro, kar za manjšo gručo pomeni 112 TB/h ali 260 Gbits/s. Upravljanje s podatki je v tem okolju torej ključnega pomena.

Gruče imajo na voljo :

scratch space – fizično na vozlišču, lokalno dostopno (na nekaterih superračunalnikih zelo hitro dostopna lokalizirana shramba)
networked job home – privzeti direktorij za nalogo, običajno na zelo hitrem, morda vzporedno dostopnem diskovnem polju, kjer je direktorij deljen z vsemi instancami iste naloge, tudi če so na različnih vozliščih
mid-term storage space – običajno večji podatkovni sistem, ki ni neposredno vključen v gručo in je lahko celo na drugi lokaciji, a omogoča srednjeročno hranjenje podatkov

Porazdeljeno omrežje

Vmesna programska oprema Grid omogoča boljše izkoristke strojne opreme, avtomatizira prenose podatkov, unificira dostop do različnih gruč ter samodejno upravljanje z uporabniki. Zaradi boljšega upravljanja pa zahteva podrobnejši opis zahtev naloge – datoteke z opisom.

Kako deluje vmesna programska oprema ARC?

Sistem ARC ima 3 vmesnike:

job submission interface – oddaja nalog
file access interface – prenos datotek
information query interface – informacijski strežnik

Glavni strežniki ARC CE:

Grid-manager = storitev za izvajanje nalog (upravljanje sistema vrst oz. LRMS)
Informacijski sistemi
Strežnik GridFTP (GFS)

Vmesniki (source: nordugrid.org)

User mapping (source: nordugrid.org):

Upravljanje z nalogami prko A-REX (vir: nordugrid.org):

Oddajanje nalog:

Uporaba odjemalca ARC

Odjemalec ARC je del vmesne programske opreme grid, s katerim uporabniki komunicirajo s sistemi, poganjajo naloge in upravljanjo s podatki. Uradna navodila: here.

Za uporabo sistema morate poznati nekaj splošno uporabnik ukazov.

Podatki o posamezni gruči so na voljo z ukaznom arcinfo:

$ arcinfo jost.arnes.si
Computing service: Arnes (production)
Information endpoint: ldap://jost.arnes.si:2135/Mds-Vo-Name=local,o=grid
Information endpoint: ldap://jost.arnes.si:2135/Mds-Vo-Name=resource,o=grid
Information endpoint: ldap://jost.arnes.si:2135/o=glue
Information endpoint: https://jost.arnes.si:443/arex
Information endpoint: https://jost.arnes.si:443/arex
Submission endpoint: https://jost.arnes.si:443/arex 
(status: ok, interface: org.ogf.bes)
Submission endpoint: https://jost.arnes.si:443/arex 
(status: ok, interface: org.ogf.glue.emies.activitycreation)
Submission endpoint: gsiftp://jost.arnes.si:2811/jobs 
(status: ok, interface: org.nordugrid.gridftpjob)

Z nalogami lahko delate preko dveh vmesnikov: HTTPS ali GRIDFTP. Želeni vmesnik in protokol lakho izberete z nastavitvami odjemalca spodaj.

Za GRIDFTP:

[computing/jost] 
url=ldap://jost.arnes.si:2135 
infointerface=org.nordugrid.ldapng 
submissioninterface=org.nordugrid.gridftpjob

Za HTTPS:

[computing/jost]
url=https://jost.arnes.si:443/arex
infointerface=org.ogf.glue.emies.resourceinfo
submissioninterface=org.ogf.glue.emies.activitycreation
default=yes

Pripravite posredniško elektronsko potrdilo

Pred komunikacjo s sistemom je treba vzpostaviti posredniško elektronsko potrdilo (proxy certificate). Posredniško potrdilo lahko vsebuje podatke o vašem članstvu v virutalni organizaciji. Predvidoma je veljavno 12 ur, mogče ga je podaljšati.

arcproxy #pripravi vmesno potrdilo - proxy
arcproxy -S gen.vo.sling.si #create a proxy for gen.vo.sling.si
arcproxy –I #check the proxy information
arcproxy -S gen.vo.sling.si -c validityPeriod=24h -c vomsACvalidityPeriod=24h
arcrenew #obnovi potrdilo

Ukazi za upravljanje z nalogami

#oddaja naloge
arcsub
arcsub –c jost.arnes.si test.xrsl 
arcsub –c jost.arnes.si test.xrsl -d DEBUG #debug mode

#status naloge
arcstat
arcstat JOBID  #check job with ID
arcstat -a #check the status of all submitted jobs

#prevere stdout/stderr naloge
arccat 
arccat JOBID or arccat -a

#prevzemi podatke naloge po izvedbi
arcget 
arcget JOBID ali arcget –a
arcget -K #keep the results on the cluster after the transmission

#prekliči/ubij nalogo
arckill #kills/cancels all active jobs
arcclean #clean the jobs

#nadaljuj z delom nalog
arcresume #required after arcrenew

Vsi ukazi imajo navodila (man pages).

Status nalog

Osnovni ukazi za uporavljanje s podatkovnimi shrambami

Delo s podatki na oddaljenem namenskem strežniku (npr. dcache.arnes.si):

arcls #seznam vsebine mape
arccp #koprija
arcrm #zbriši
arcmkdir #naredi direktorij
arcrename #preimenuj dokument

Drugi koristni ukazi

arcinfo jost.arnes.si #podatki o gruči
arcsync #osveži seznam nalog
arctest #odpošlji testno nalogo

Reševanje težav

Če pride do napak, je korisno dobiti vpogled v dnevniške zapise, kjer so zapisani poteki različnih koponent; naslednja nastavitev v xRSL zahteva, da se vse te datoteke prenese v mapi log/:

(gmlog="log")

Primer:

cat log/failed
LRMS error: (-1) Job was cancelled

Ta izpis v primeru, da uporabnik ni zamenoma prekinil naloge, pomeni, da je sistem ob pripravi naloge naletel na napako; pogledamo v datoteko log/errors log:

cat log/errors
job submitted successfully!
local job id: 2078340
----- exiting submit_slurm_job -----

2017-10-04T12:36:46Z Job state change SUBMIT -> INLRMS   Reason: Job is passed to LRMS
------- Contents of output stream forwarded by the LRMS ---------
slurmstepd: error: Job 2078340 exceeded virtual memory limit (134084 > 4096), being killed
/bin/bash: error while loading shared libraries: libdl.so.2: failed to map segment from shared object
slurmstepd: error: Exceeded job memory limit
------------------------- End of output -------------------------
2017-10-04T12:37:41Z Job state change INLRMS -> FINISHING   Reason: Job processing error
2017-10-04T12:37:41Z Job state change FINISHING -> FINISHED   Reason: Job processing error

Razvidno je (“job submitted successfully”), da je strežnik uspešno zagnal nalogo preko sistema vrst (LRMS). V izpisu LRMS je vidno, da je naloga presegla napovedani maksimalni pomnilnik, zato jo je sistem ubil.

xRSL: opis nalog

Navodila: http://www.nordugrid.org/documents/xrsl.pdf

Programska okolja: Runtime environments

Na sistemu je vrsta vnaprej nameščenih programskih paketov, knjižnic in okolij. Seznam lahko najdete na spletni strani Grid Monitor ali z neposrednim poizvedovanjem:

ldapsearch -x -h jost.arnes.si -p 2135 -b ' Mds-Vo-name=local,o=grid' 
| grep nordugrid-cluster-runtimeenvironment

Programe lahko pošljete tudi kot del podatkov z nalogo, vendar je priporočjivo, da ne presegajo 100MB. Prav tako je mogoče v okviru naloge zaganjati prevajalnike.

Če potrebujete kakšno programsko opremio, nas obvestite na support@sling.si oz. se obrnite na lokalne upravitelje. Programe lahko tudi prenesete na strežnik za podatke (dcache.arnes.si) in jih zahtevate v datoteki xrsl.

Nastavitev želenega okolja:

(runtimeenvironment="APPS/BASE/GPU"

Uporaba OpenMPI in omrežja infiniBand

Omrežje InfiniBand omogoča nizkolatenčno komunikacijo v večjedrnih nalogah.

Prvi primer z OpenMPI:

Program v jeziku C: hellompi.c

/* C Example */
#include <stdio.h>
#include <mpi.h> 


int main (argc, argv)
     int argc;
     char *argv[];
{
  int rank, size;

  MPI_Init (&argc, &argv);      /* starts MPI */
  MPI_Comm_rank (MPI_COMM_WORLD, &rank);        /* get current process id */
  MPI_Comm_size (MPI_COMM_WORLD, &size);        /* get number of processes */
  printf( "Hello world from process %d of %dn", rank, size );
  MPI_Finalize();
  return 0;
}

Skripta, ki bo program prevedla in zagnala:

#!/bin/bash
date
hostname
echo "Compiling example"
mpicc -o hello hellompi.c
echo "Done."
echo "Running example:"
mpirun --mca btl openib,self -np 4 ${PWD}/hello > hellompi.out
echo "Done."
date

Opis naloge xrsl:

&
(count = 4)
(jobname = "hellompi")
(inputfiles =
  ("hellompi.sh" "")
  ("hellompi.c" "")
)
(outputfiles = 
  ("hellompi.out" "")
)
(executable = "hellompi.sh")
(stdout = "hellompi.log")
(join = yes)
(walltime = "15 minutes")
(gmlog = log)
(memory = 2000)
(runtimeenvironment = "APPS/BASE/OPENMPI-2.1")
(reuntimeenvirnment = "RESV/FRI")

Za zagon več jeder na istem računalniku zahtevate count=4 in countpernode=4. Pri večjih nalogah (več kot 30 jeder) je priporočljivo, da omejite število vozlišč, sicer se lahko naloge preveč razpršijo in učinkovitost pade.

Naloge z vektorskimi/grafilčnimi procesorji GPGPU s pomočjo CUDA

Z nalogo bomo izmerili pasovno širino pomnilika do kartice:

Najprej program cudatest.cu:

#include <stdio.h>  

int main() {
  int nDevices;

  cudaGetDeviceCount(&nDevices);
  for (int i = 0; i < nDevices; i++) {
    cudaDeviceProp prop;
    cudaGetDeviceProperties(&prop, i);
    printf("Device ID: %dn", i);
    printf("  GPU, device name: %sn", prop.name);
    printf("  Memory Clock Rate (KHz): %dn",
           prop.memoryClockRate);
    printf("  Memory Bus Width (bits): %dn",
           prop.memoryBusWidth);
    printf("  Peak Memory Bandwidth (GB/s): %fnn",
           2.0*prop.memoryClockRate*(prop.memoryBusWidth/8)/1.0e6);
  }
}

Skripta cudatest.sh:

#!/bin/bash
env| grep -i cuda > cudaenv.out
nvcc cudatest.cu -o cudatest
./cudatest > cudatest.out

Opis naloge:

&
(executable="cudatest.sh")
(inputfiles=
  ("cudatest.sh" "")
  ("cudatest.cu" "")
)
(outputfiles=
  ("cudatest.out"  " ")
  ("cudaenv.out"  " ")
)
(stdout="error.txt")
(join=yes)
(gmlog="log")
(jobName="cudatest")
(walltime="10")
(count="1")
(memory="500")
(runtimeenvironment="APPS/BASE/GPU")

Anatomija vsebnikov

Običajna hierarhija posla v sistemu je nekako takšna:

INIT
ARC Manager + subsystems
SLURM
job scripts
RunTime Environment scripts
job start script

Vsebniki omogočajo bistveno bolj fleksibilno okolje – vključimo pa jih lahko na različnih ravneh. Naslednji primeri v vsebniku kažejo okolje, podobno standarnemu okolju POSIX.

Osnovni primeri uporabe

(Te primere lahko preizkusite v testnem okolju, ki je na voljo za delavnico.)

Nov vsebnik iz repozitorija:

 singularity pull docker://ubuntu:latest #bad example for real use

Ima kakšne oznake?

singularity inspect ubuntu-latest.simg


 {
 "status": 404,
 "detail": "This container does not have labels",
 "title": "Labels Undefined"
 }

Poženimo shell:

singularity shell ubuntu-latest.simg 
# You get your own home directory again - it is automounted
# but

 uname -a
 Linux 308.ablak.arnes.si 2.6.32-696.18.7.el6.x86_64 #1 SMP Thu Jan 4 17:31:22 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

cat /etc/lsb-release
 DISTRIB_ID=Ubuntu
 DISTRIB_RELEASE=16.04
 DISTRIB_CODENAME=xenial
 DISTRIB_DESCRIPTION="Ubuntu 16.04.3 LTS

Vsebnik s strežnikov Docker ali Singularity hub

Nekateri so bolj “zabavni”, zaženemo pa jih lahko neposredno, ne da bi jih najprej uvozili:

singularity exec --nv docker://nvidia/cuda:latest nvcc --version
Docker image path: index.docker.io/nvidia/cuda:latest
Cache folder set to /net/jost/home/gen009/.singularity/docker
[10/10] |===================================| 100.0% 
Creating container runtime...
tar: usr/local/cuda-9.0/.wh..wh..opq: implausibly old time stamp 1970-01-01 01:00:00
tar: usr/share/doc/cuda-cudart-9-0/.wh..wh..opq: implausibly old time stamp 1970-01-01 01:00:00
...
...

WARNING: Skipping user bind, non existent bind point (file) in container: '/usr/bin/nvidia-smi'
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2017 NVIDIA Corporation
Built on Fri_Sep__1_21:08:03_CDT_2017
Cuda compilation tools, release 9.0, V9.0.176

Ali zadnji Ubuntu:

$ singularity exec docker://ubuntu:latest echo "Hello from the container"
Docker image path: index.docker.io/library/ubuntu:latest
Cache folder set to /net/jost/home/gen009/.singularity/docker
Creating container runtime...
Hello from the container

singularity pull docker://ubuntu:latest
singularity build ubuntu.img docker://ubuntu:latest

$ singularity exec docker://fedora:latest cat /etc/redhat-release
Docker image path: index.docker.io/library/fedora:latest
Cache folder set to /net/jost/home/gen009/.singularity/docker
[1/1] |===================================| 100.0%
Creating container runtime...
WARNING: Could not chdir to home: /net/jost/home/gen009
Fedora release 26 (Twenty Six)

Vrsta vnaprej pripravljenih vsebnikov je na voljo na strežniku Singularity Hub:

https://singularity-hub.org/collections

Njegova največja prednost pa je, da omogoča gradnjo vsebnikov v oblaku preko povezanih repozitorijev receptov v sistemu github.

Priprava lastnih sistemskih slik za vsebnike – interaktivna

Interaktivna raba zahteva administratorske pravice – na virtualnem stroju jih nimate.

$ sudo singularity build --sandbox ubuntu/ docker://ubuntu
Docker image path: index.docker.io/library/ubuntu:latest
Cache folder set to /root/.singularity/docker
Importing: base Singularity environment
Importing: /root/.singularity/docker/sha256:9fb6c798fa41e509b58bccc5c29654c3ff4648b608f5daa67c1aab6a7d02c118.tar.gz
Importing: /root/.singularity/docker/sha256:3b61febd4aefe982e0cb9c696d415137384d1a01052b50a85aae46439e15e49a.tar.gz
Importing: /root/.singularity/docker/sha256:9d99b9777eb02b8943c0e72d7a7baec5c782f8fd976825c9d3fb48b3101aacc2.tar.gz
Importing: /root/.singularity/docker/sha256:d010c8cf75d7eb5d2504d5ffa0d19696e8d745a457dd8d28ec6dd41d3763617e.tar.gz
Importing: /root/.singularity/docker/sha256:7fac07fb303e0589b9c23e6f49d5dc1ff9d6f3c8c88cabe768b430bdb47f03a9.tar.gz
Importing: /root/.singularity/metadata/sha256:22e289880847a9a2f32c62c237d2f7e3f4eae7259bf1d5c7ec7ffa19c1a483c8.tar.gz
Building image from sandbox: ubuntu/
Singularity container built: ubuntu/

Vsebnik je nameščen v poddirektorj – kjer ga lahko editiramo.

Lahko tudi preko ukazne lupine v vsebniku nameščamo programe:

$ singularity shell --writable ubuntu
Singularity: Invoking an interactive shell within container...

Pomemben je parameter –writable

Po spremembah naredimo read-only production image (produkcijsko sistemsko sliko brez možnosti spreminja):

sudo singularity build ubuntu.simg ubuntu/

Binding in sloji

Singularity ima več opcij za bind-mounting v vsebnikih, tudi interaktivno:

singularity shell --bind /tmp ubuntu

Omogoča binding v sistemskih nastavitvah in v receptu za vsebnik (pomembno za prenos nameščenih knjižnic ipd.)

Lahko pa vsebniku dodamo tudi dodaten sloj, npr. za možnost pisanja, začasne datoteke ali za več različic:

singularity image.create my-overlay.img
sudo singularity shell --overlay my-overlay.img ubuntu.simg

V dodatnem sloju se ohranjajo spremembe, kakor bi vsebnik omogočal pisanje…

Priprava lastnih sistemskih slik za vsebnike – z receptom

To je zaželena oblika za vsebnike, ki jih v vašem imenu namestimo na gručo!

Format opisne datoteke – recepta:

BootStrap: docker
From: ubuntu:16.04

%post
    apt-get -y update
    apt-get -y install fortune 

%environment
    export LC_ALL=C
    export PATH=/usr/games:$PATH

%runscript
    echo "Hello world"

sudo singularity build helloworld.simg helloworld.dsc

sudo singularity build --environment helloworld.simg helloworld.dsc

Lahko uporabite le posamezen segment in posodobite vsebnik.

Ta pristop podpira tudi modularne vsebnike (z aplikacijami), SingularityHub pa je integriran sistem za gradnjo vsebnikov z GitHuba.

Seveda lahko enako naredite tudi neposredno z orodji za gradnjo distribucij; npr. za Debian (ali Ubuntu):

BootStrap: debootstrap
OSVersion: stable
MirrorURL: http://ftp.us.debian.org/debian/


%runscript
 echo "This is what happens when you run the container..."
 cat /etc/os-release

%post
 apt-get update
 apt-get -y install fortune cowsay lolcat
 apt-get clean

%environment
 export PATH="$PATH:/usr/games"

Vsebniki (containers) ali lahka virtualizacija so utečen postopek, znane implementacije so npr BSD Jails, Solaris Security Zones. V sistemih na osnovi jedra Linux je bilo več implementacij, ki niso bile del uradnega jedra, dokler ni na osnovi razvoja vrste vmesnikov in tehnologij prišlo do zelo fleksibilne implementacije vsebnikov Linux (Linux Containers).

Vsebniki v kontekstu GNU/Linux temeljijo na naslednjih tehnologijah:

Capabilities
Name Spaces
Control Groups
Napredni datotečni sistemi (bind-mounts, squashfs, overlayfs ipd.)

Capabilites

Od Linux 2.2 capabilities predstavljajo modularna dovoljenja (kar je v Unixu klasično pomenil dostop “superuser” oz. “root/admin”).

Nekaj primerov:

CAP_SYS_ADMIN – Overloaded with many admin permissions, including many for namespaces
CAP_SYS_CHROOT – Chroot and filesystem namespaces
CAP_CHOWN – Make arbitrary changes to file UIDs and GIDs (see chown(2)).
CAP_DAC_OVERRIDE – Bypass file read, write, and execute permission checks.
CAP_NET_ADMIN – Perform various network-related operations

Name Spaces in Namespace Isolation

Generaliziran mehanizem za izolacijo skupin procesov ter segmentov diskovja (tudi chroot).
Konceptualno že v Plan9, HURD.

 A namespace wraps a global system resource in an abstraction that makes it appear to
 the processes within the namespace that they have their own isolated instance of the
 global resource. Changes to the global resource are visible to other processes that
 are members of the namespace, but are invisible to other processes. One use of names‐
 paces is to implement containers.

Network namespace – isolates the network interface controllers (physical or virtual), iptables firewall rules, routing tables etc. Network namespaces can be connected with each other using the “veth” virtual Ethernet device.
“UTS” namespace – allows changing the hostname.
Mount namespace – allows creating a different file system layout, or making certain mount points read-only.
IPC namespace – isolates the System V inter-process communication between namespaces.
User namespace – isolates the user IDs between namespaces.
User namespaces isolate security-related identifiers and attributes, in particular, user IDs and group IDs, the root directory, keys, and capabilities.
Control Group – recent, to hide control group hierarchy

Lahko jih tudi gnezdimo!

Sistemski vmesnik (iz priročnika / man pages):

The child process created by clone(2) with the CLONE_NEWUSER flag starts out with a
complete set of capabilities in the new user namespace. Likewise, a process that cre‐
ates a new user namespace using unshare(2) or joins an existing user namespace using
setns(2) gains a full set of capabilities in that namespace. On the other hand, that
process has no capabilities in the parent (in the case of clone(2)) or previous (in
the case of unshare(2) and setns(2)) user namespace, even if the new namespace is cre‐
ated or joined by the root user (i.e., a process with user ID 0 in the root names‐
pace)

Tudi ukaz (in funkcija) unshare, funkcije clone(2) and unshare(2), tudi setns(<path>) z ustrezno nastavitvijo SAP_SYS_<capability>.

$ sudo unshare --fork --pid --mount-proc bash

Control Groups (cgroups)

Delujejo na hierarhičnih skupinah procesov in omogočajo:

omejitev virov (Resource limiting) – groups can be set to not exceed a configured memory limit, which also includes the file system cache
prioritete (Prioritization) – some groups may get a larger share of CPU utilization[10] or disk I/O throughput
spremljanje porabe virov (Accounting) – measures a group’s resource usage, which may be used, for example, for billing purposes
upravljanje (Control) – freezing groups of processes, their checkpointing and restarting

Delujejo na posamezne “kontrolerje” (sistemske sklope sistemskega jedra), glej:

 cat /proc/cgroups #available controllers
 cat /proc/<num>/cgroups #pid belongs to groups

Sistemski sklopi:

blkio — this subsystem sets limits on input/output access to and from block devices such as physical drives (disk, solid state, or USB).
cpu — this subsystem uses the scheduler to provide cgroup tasks access to the CPU.
cpuacct — this subsystem generates automatic reports on CPU resources used by tasks in a cgroup.
cpuset — this subsystem assigns individual CPUs (on a multicore system) and memory nodes to tasks in a cgroup.
devices — this subsystem allows or denies access to devices by tasks in a cgroup.
freezer — this subsystem suspends or resumes tasks in a cgroup.
memory — this subsystem sets limits on memory use by tasks in a cgroup and generates automatic reports on memory resources used by those tasks.
net_cls — this subsystem tags network packets with a class identifier (classid) that allows the Linux traffic controller (tc) to identify packets originating from a particular cgroup task – and then handle them using services sucha as veth and virtual routers.
net_prio — this subsystem provides a way to dynamically set the priority of network traffic per network interface. ns (obsolete) — the namespace subsystem.
perf_event — this subsystem identifies cgroup membership of tasks and can be used for performance analysis

Dodatno varnostno orodje

seccomp-bpf — kernel feature that lets you filter which system calls your process can run

Standardna orodja so v paketih libcgroup libcgroup-tools in na sistemih z systemd tipično niso prednameščena:

 mount -t cgroup -o controller_name none /sys/fs/cgroup/controller_name
 lssubsys -am
 cgexec -g controllers:<path_to_cgroup> <command> <arguments

Pogosto jih uporabljamo kar preko systemd init sistema, ki jih konceptualizira drugače

service (systemd-started processes)
scope (their children)
slice (their cgroup hierarchies)

The kink of systemd – ročna uporaba na ta način:

systemd-run --unit=<name> --scope --slice=<slice_name> <command>

Systemd servise upravlja kot “persistentne cgroupe”.

… in preko orodij za uporavljanje z vsebniki (lxc, docker ipd.)

Orodja na osnovi teh mehanizmov so številna, najbolj znana:

container managers:
LXC (LinuX Containers), LXD, virsh CoreOS, Docker, Jelastic, lmctfy (deceased), Singularity
app & system managers: Kubernetes, Mesos and Mesosphere
system tools:
systemd, specifična orodja
HPC managers and schedulers:
slurm, HTCondor, Hadoop

Kaj je torej vsebnik?

Skupina procesov z dovolj veliko mero izolacije, tipično: omrežje, uporabniki, procesi in diskovje. Vendar je sistem na osnovi zgornjih mehanizmov dovolj fleksibilen, da so različne možnosti.

LXC/LXD vs Docker

LXC je osnovno orodje za linux vsebnike, ki pa se ga zdaj manj uporablja, ker je prevladal docker. Ima vrsto opcij, po funkcijah je blizu sistemu BSD jail. Privzeto sistem naredi vsebnik s celotnim nameščenim operacijskim sistemom (kakor chroot) v poddirektoriju z lastnim mrežnim, procesnim in uporabniškim kontekstom.

V primerjavi s tem pristopom ima Docker vrsto prednosti:

podpora za minimalistične vsebnike (busybox, bindmounts)
komprimirane sistemske slike (squashfs)
sistem za uporavljanje s slednjimi + repozitorij
možnost kompozicije vsebnikov
integracija z systemd
format in kompatibilnost (celo implementacije za druge sisteme)

Posledično je sistem zanimiv za splošno uporabo lahke virtualizacije, vendar ni optimiziran za uporabo z enkratnim zagonom, s specifično strojno opremo (superračunalniki) in mrežnimi/paralelnimi datotečnimi sistemi.

Docker in HPC

kompliciran (nadgrajevanje, kompozicija vsebnikov, zunanji viri)
namenjen za servise in pogojno cele sisteme, ni namenjen za zagon posameznih ukazov
izoliran (težko mapirati generične dele diskovja, home directory ipd.)
poskuša nadzirati uporabo virov (v HPC okolju imamo za to druga orodja)

Torej: privzeti mehanizmi v nasporotju s tem, kar potrebujemo v okolju HPC.

Posledično je v okolju HPC nastalo več projektov za lahko virutalizacijo v superračunalniških omrežjih, najbolj znana sta Shifter (močno vpet v slurm) in Singularity: http://singularity.lbl.gov/

Docker vs Singularity

Nekaj skupnih lastnosti:

stateless container
repositories
build systems
compatibility

Vendar je Singularity optimiziran za izvajanje enkratnih procesov v superračunalniškem okolju, kjer sistem vrst (batch system) skrbi za omejevanje in obračunavanje virov, diskovni sistemi so pogosto omrežni, podatki pa pogosto zelo veliki.

Ponovimo:

uporabnik enak v sistemu in zunaj; administratorski dostop (root) ima samo administrator
običajno uporabljamo sistemske slike, ki jih lahko samo beremo
IO teče skozi vsebnik – vključno z diskovnim dostopom
ne vpliva na hitrost
nekaj omejitev: gonilniki, stabilnost overlayfs ipd – zelo učinkovit v večini primerov
soopravilnost z dockerjem
kompliciran svet: omogoča tudi aplikacije (z več plastmi) in instance (zagon kot servis)

Sistem omogoča naloge, ki imajo povsem nedvisno okolje, zato lahko tečejo v enakem okolju na razlilčnih fizičnih gručah in tudi osebnih računalnikih.

Lahka vitualizacija na gruči

Včasih so vnaprej pripravljena okolja (runTimeEnvironemnents) na gručah implementirana kot vsebniki Singularity – bodisi zaradi lažje namestitve, zaradi lažjih nadgradenj ali zato, ker lahko na ta način več gruč uporablja enake sistemske slike. Če želite, nam lahko pošljete recept, da vam ga namestimo. To je za vse vpletene najlažji način nameščanja programske opreme v superračunalniško okolje.

Za uporabo vnaprej pripravljenega okolja, nameščenega na gručo, lahko (s podatkom o lokaciji) v skripti zaženete neposredno aplikacijo v vsebniku:

$ singularity exec /grid/arc/sw/singularity/cuda-latest.img cat /etc/os-release
NAME="Ubuntu"
VERSION="16.04.3 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.3 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial

Uporaba sistemske slike z zunanjega vira

Je zelo preprosta, saj lahko uporabite enak pristop kot pri neposrednem zaganjanju na svojem računalniku. Pripravimo skripto in opis naloge:

sing-test.sh:

singularity exec /grid/arc/sw/singularity/cuda-latest.img cat /etc/os-release

job.xrsl:

&
(executable="sing-test.sh")
(stdout="stdout.txt")
(join=yes)

Pri tem načinu seveda izvajamo prenose na sistemskih slik na gručo. Ob množični uporabi je smiselno, da upravitelji gruče vzpostavijo spletni posrednik z vmesnim pomnilnikom (caching proxy) ali lastni hub.

Uporaba lastne sistemske slike

Sistemske slike lahko shranite na zunanji strežik (npr. https, ftp) ali strežnik za podatke, npr. dCache. Potem sliko navedete kot vhodno datoteko (InputFiles v xrsl) ter jo uporabite v skripti.

Primer z vsebnikom helloworld.simg – ki smo ga zgoraj pripravili z receptom:

singularity-hello-world.sh:

singularity exec helloworld.simg cat /etc/lsb-release

job.xrsl:

&
(executable="singularity-hello-world.sh")
(stdout="stdout.txt")
(join=yes)
(inputfiles
  ("helloworld.simg" "")
)

Ko boste nalogo odposlali z arcsub, bo odjemalec prenesel tudi vsebnik, sistem pa ga bo odložil v delovno mapo naloge. Tako bo datoteka na voljo za uporabo v skripti.

Primer: Keras + Tensorflow

Najprej na osnovi standarnih vsebnikov Docker pripravimo ustrezno okolje (hvala Barbari Krašovec).

BootStrap: docker
From: nvidia/cuda:9.0-cudnn7-runtime-ubuntu16.04

%labels

%environment
export PATH=/bin:/usr/bin:/usr/local/bin:/usr/local/cuda/bin:
export LC_ALL=C

%post
apt-get update
apt-get install -y libhdf5-dev graphviz locales python3-dev python3-pip
apt-get clean

pip3 install tensorflow-gpu==1.8.0
pip3 install keras==2.1.6
pip3 install numpy Pillow scikit-learn pandas\
 matplotlib notebook ipython h5py liac-arff openpyxl xlsxwriter

# create some generic mount points
mkdir -p /var/spool/slurm 
mkdir /cvmfs /grid /data1 /data2 /data0 
touch /bin/nvidia-smi
# jost and nsc
mkdir -p /net/jost/home /d/hpc/session /d/hpc/cache
mkdir -p /net/hold/data1

Preprosta testna skripta:

from __future__ import print_function
import tensorflow as tf

# Simple hello world using TensorFlow
hello = tf.constant('Hello, TensorFlow!')

# Start tf session
sess = tf.Session()

# Run the operation
print(sess.run(hello))

Ali, malce zahtevneje:

import tensorflow as tf

config = tf.ConfigProto()
config.gpu_options.allow_growth=True
sess = tf.Session(config=config)

# Creates a graph.
a = tf.constant([1.0, 2.0, 3.0, 4.0, 5.0, 6.0], shape=[2, 3], name='a')
b = tf.constant([1.0, 2.0, 3.0, 4.0, 5.0, 6.0], shape=[3, 2], name='b')
c = tf.matmul(a, b)
# Creates a session with log_device_placement set to True.
sess = tf.Session(config=tf.ConfigProto(log_device_placement=True))
# Runs the op.
print(sess.run(c))

Dodatno gradivo in primeri

Prilagajanje vsebnikov z DockerHuba ali drugih virov

FROM tensorflow/tensorflow:1.10.0-gpu-py3

RUN apt update && \
 apt install -y git-core 
 
RUN mkdir /grid && \
 mkdir -p /net/jost/home && \
 mkdir /cvmfs && \
 mkdir -p /d/hpc/session && \
 mkdir -p /var/spool/slurm &&\
 mkdir -p /d/hpc/session

Uvažanje zasebnega vsebnika z DockerHuba

export SINGULARITY_DOCKER_USERNAME=my_username
export SINGULARITY_DOCKER_PASSWORD=my_password

# NSC is IPv6 only needs proxy
git config –global https.proxy http://www-proxy.ijs.si:8080 &&\
git config –global http.proxy http://www-proxy.ijs.si:8080

#certificate errors?
SINGULARITY_NOHTTPS=true sudo singularity build –sandbox tensorflow/ docker://tensorflow

Uporaba vsebnikov in MPI

Singularity je nastal z mislijo na oprimizacijo za superračunalniško okolj, za je MPI neposredno integriran in deluje brez posebne intervencije uporabnika: če pokličete singularity exec preko mpirun (oz. ko ga pokliče sistem), singularity transparetno vzpostavi povezavo med procesom ORTED in aplikacijo oz. MPI knjižnico preko PMI (Process Management Interface) in aplikacija deluje normalno.

Za ilustracijo kompleten primer vsebnika za QuantumExpress (courtesy by Barbara Krašovec, kot vsi kompletni primeri); v tem primeru recept temelji na Centos 7 z Docker Hub in vsebuje prevajanje in namestitev OpenMPI in QuantumExpresso:

Bootstrap: docker
From: centos:latest

%setup

%runscript
 echo "Running the container..."

%post
 echo "Installing the packages inside the container"
 yum -y update

echo "Adding repos"
 yum -y install epel-release

echo "Installing prerequisites"
 yum -y install awk sed wget make gcc-gfortran gcc libgfortran openblas-devel openblas lapack lapack-devel fftw fftw-devel perl-devel gcc-c++

echo "Set locale"
 export LC_ALL=C

echo "Builing OpenMPI"
 cd /opt
 wget https://www.open-mpi.org/software/ompi/v2.1/downloads/openmpi-2.1.2.tar.gz
 tar xvzf openmpi-2.1.2.tar.gz
 cd openmpi-2.1.2
 mkdir build || echo "folder build exists"
 ./configure --prefix=/opt/openmpi-2.1.2/build
 make all
 make all install
 cd ..
 rm -rf /opt/openmpi-2.1.2.tar.gz

echo "Add OpenMPI to PATH"
 export LD_LIBRARY_PATH=/opt/openmpi-2.1.2/build/lib:$LD_LIBRARY_PATH
 echo 'LD_LIBRARY_PATH=/opt/openmpi-2.1.2/build/lib:$LD_LIBRARY_PATH' >>$SINGULARITY_ENVIRONMENT
 export PATH=/opt/openmpi-2.1.2/build/bin:$PATH
 echo 'PATH=/opt/openmpi-2.1.2/build/bin:$PATH' >>$SINGULARITY_ENVIRONMENT

echo "Building Quantum Espresso"
 cd /opt
 wget http://www.qe-forge.org/gf/download/frsrelease/247/1132/qe-6.2.1.tar.gz
 tar xvzf qe-6.2.1.tar.gz
 cd qe-6.2.1
 mkdir build || echo "folder build exists"
 ./configure --prefix=/opt/qe-6.2.1/build
 make all
 make install
 rm -rf /opt/qe-6.2.1.tar.gz

echo "Adding QE to PATH"
 export LD_LIBRARY_PATH=/opt/qe-6.2.1/build/lib:$LD_LIBRARY_PATH
 echo 'LD_LIBRARY_PATH=/opt/qe-6.2.1/build/lib:$LD_LIBRARY_PATH' >>$SINGULARITY_ENVIRONMENT
 export PATH=/opt/qe-6.2.1/build/bin:$PATH
 echo 'PATH=/opt/qe-6.2.1/build/bin:$PATH' >>$SINGULARITY_ENVIRONMENT
 export RTEHOME=/opt/qe-6.2.1/build
 export MPIHOME=/opt/openmpi-2.1.2/build
 echo 'RTEHOME=/opt/qe-6.2.1/build' >>$SINGULARITY_ENVIRONMENT
 echo 'MPIHOME=/opt/openmpi-2.1.2/build' >>$SINGULARITY_ENVIRONMENT

echo "Post done."

Pripravljen je generičen vsebnik s QuantumExpresso s podporo za MPI!

Primer uporabe preprostega vsebnika preko vmesnika MPI:

# singularity slika s knjižnicami

mpicc -o hellompi singularity exec -B /net/jost/home /grid/arc/sw/singularity/test.img $HOME/hellompi.c
mpirun singularity exec -B /net/jost/home /grid/arc/sw/singularity/test.img $HOME/hellompi

# če za NV poti niso nastavljene v sliki:
SINGULARITYENV_LD_LIBRARY_PATH=/usr/local/cuda-7.5/lib64:/usr/local/cuda-7.5/include \SINGULARITYENV_PATH=/usr/local/cuda-7.5/bin singularity exec --nv -B \ /var/spool/slurm,/cvmfs,/net/jost/home,/d/hpc/cache,/d/hpc/session /grid/arc/sw/singularity/test.img echo $LD_LIBRARY_PATH

Vsebniki in GPGPU / CUDA

Podpora za prevezave in bind-mounting za Singularity pomeni, da je mogoče različne sistemske knjižnice in vmesnike do strojne opreme “izvoziti” v vsebnik in tako omogočiti neposreden dostop do njih. Od različice 2.3 pa ima Singularity neposredno podporo za uvoz gonilnikov in vmesnikov za grafične koprocesorje (GPGPU) ter knjižnice CUDA, ki jih lahko pokličem s stikalom –nv

singularity exec --nv ubuntu.simg <command>

Sistem samodejno uvozi naslednje knjižnice:
Found NV library: /lib64/libnvidia-tls.so.387.34
Found NV library: /lib64/libnvidia-tls.so.370.28
Found NV library: /lib64/libnvidia-ptxjitcompiler.so.370.28
Found NV library: /lib64/libnvidia-ptxjitcompiler.so.1
Found NV library: /lib64/libnvidia-opencl.so.1
Found NV library: /lib64/libnvidia-ml.so.1
Found NV library: /lib64/libnvidia-ml.so
Found NV library: /lib64/libnvidia-glsi.so.387.34
Found NV library: /lib64/libnvidia-glsi.so.370.28
Found NV library: /lib64/libnvidia-glcore.so.387.34
Found NV library: /lib64/libnvidia-glcore.so.370.28
Found NV library: /lib64/libnvidia-fatbinaryloader.so.387.34
Found NV library: /lib64/libnvidia-fatbinaryloader.so.370.28
Found NV library: /lib64/libnvidia-encode.so.1
Found NV library: /lib64/libnvidia-eglcore.so.387.34
Found NV library: /lib64/libnvidia-eglcore.so.370.28
Found NV library: /lib64/libnvidia-egl-wayland.so.370.28
Found NV library: /lib64/libnvidia-egl-wayland.so.1
Found NV library: /lib64/libnvidia-compiler.so.387.34
Found NV library: /lib64/libnvidia-compiler.so.370.28
Found NV library: /lib64/libnvidia-cfg.so.1
Found NV library: /lib64/libnvcuvid.so.1
Found NV library: /lib64/libcuda.so.1
Found NV library: /lib64/libcuda.so
Found NV library: /lib64/libOpenGL.so.0
Found NV library: /lib64/libOpenCL.so.1
Found NV library: /lib64/libGLdispatch.so.0
Found NV library: /lib64/libGLX_nvidia.so.0
Found NV library: /lib64/libGLX.so.0
Found NV library: /lib64/libGLESv2_nvidia.so.2
Found NV library: /lib64/libGLESv2.so.2
Found NV library: /lib64/libGLESv1_CM_nvidia.so.1
Found NV library: /lib64/libGLESv1_CM.so.1
Found NV library: /lib64/libGL.so.1
Found NV library: /lib64/libEGL_nvidia.so.0
Found NV library: /lib64/libEGL.so.1

Knjižnice CUDA (CUDA toolkit) se na ta način ne namestijo v celoti, zato jih je treba namestiti v vsebniku. Ker je mogoče hkrati namestiti več različic CUDA, ni težko pripraviti splošno uporabnega (generičnega) vsebnika za GPU.

Okolje CUDA se v tem primeru izbere z izvozov spremenljivke LD_LIBRARY_PATH.

Primer za recept za vsebnik:

wget https://developer.nvidia.com/compute/cuda/8.0/Prod2/local_installers/cuda_8.0.61_375.26_linux-run 
chmod +x cuda_8.0.61_375.26_linux-run
./cuda_8.0.61_375.26_linux-run --toolkit --toolkitpath=/usr/local/cuda-8.0 --override --silent
rm -rf cuda_8.0.61_375.26_linux-run
export LD_LIBRARY_PATH=/usr/local/cuda-8.0/lib64:/usr/local/cuda-8.0/include:$LD_LIBRARY_PATH
echo 'LD_LIBRARY_PATH=/usr/local/cuda-8.0/lib64:/usr/local/cuda-8.0/include:$LD_LIBRARY_PATH' >>$SINGULARITY_ENVIRONMENT

Lahko pa spremenjivke nastavite v sekciji %environment recepta za vsebnik:

 %environment export LD_LIBRARY_PATH=/usr/local/cuda-8.0/lib64:/usr/local/cuda-8.0/include:$LD_LIBRARY_PATH If you want to avoid this entirely in the image, you can simply run the container by: SINGULARITYENV_LD_LIBRARY_PATH=/usr/local/cuda-8.0/lib64:/usr/local/cuda-8.0/include:$LD_LIBRARY_PATH singularity exec --nv ubuntu.img <command>

Če so na voljo ustrezne predpripravljene sistemske slike, jih seveda lahko uporabite tako, da uporabite Docker ali Singularity hub, lahko tudi neposredno:

singularity exec --nv docker://tensorflow/tensorflow:latest-gpu python /tmp/tensorflow-mnist.py

Lahko pa tudi uporabite metodo “–sandbox”, da iz njih pripravite nove, prilagojene sistemske slike za vsebnike.

Če želite uporabljati OpenCL, bo sistem iskal gonilnike za OpenCL drivers v obliki datoteke .icd (.icd = installable client drivers). Na RHEL jih najdete v direktoriju /etc/OpenCL/vendors – in tega je treba uvoziti (–bind) v vsebnik.

Dejanski primer recepta:

Bootstrap: docker
From: centos:latest

%setup 

%runscript
    echo "Running the container..."


%post
    echo "Installing the packages inside the container"
        yum -y update

    echo "Adding repos"
        yum -y install epel-release
        
    echo "Installing prerequisites"
        yum -y install awk sed wget make gcc gcc-c++ python34 python34-pip python34-devel libffi-devel perl perl-devel binutils-devel glib2-devel

    echo "Set locale"
        export LC_ALL=C

    mkdir /usr/include/cuda || echo "cuda folder exists"
    touch /bin/nvidia-smi || echo "file exists"

    echo "Installing CUDA Toolkit"
    wget https://developer.nvidia.com/compute/cuda/9.0/Prod/local_installers/cuda_9.0.176_384.81_linux-run
    chmod +x cuda_9.0.176_384.81_linux-run
    ./cuda_9.0.176_384.81_linux-run --toolkit --toolkitpath=/usr/local/cuda-9.0 --override --silent
    export LD_LIBRARY_PATH=/usr/local/cuda-9.0/lib64:$LD_LIBRARY_PATH
    echo 'LD_LIBRARY_PATH=/usr/local/cuda-9.0/lib64:$LD_LIBRARY_PATH' >>$SINGULARITY_ENVIRONMENT
    rm -rf cuda_9.0.176_384.81_linux-run 

    echo "Install python packages"
        pip3 install --upgrade pip
        pip3 install --upgrade numpy
        pip3 install --upgrade scipy
        pip3 install --upgrade matplotlib
        pip3 install --upgrade mako
        pip3 install --upgrade cffi
    echo "Installing pyopencl"
        pip3 install --upgrade --global-option=build_ext  --global-option="-I/usr/local/cuda-9.0/lib64:/usr/local/cuda-9.0/include" --global-option="-L/usr/local/cuda-9.0/lib64:/usr/local/cuda-9.0/include" pyopencl

(Pripravil Jan Jona Javoršek, večino izvirnega gradiva in primerov ter vse napredne recepte pripravila Barbara Krašovec, strokovna podpora Dejan Lesjak in Peter Kacin)