HTML

Az élet kódjai

Csináld maga. Senki nem csinálja meg helyetted.

Friss topikok

Vesztes csaták megvívása

2020.03.13. 15:13 Travis.CG

Ha egy munkán elsőre látszik, hogy biztosan nem lesz belőle értelmes eredmény, azt nem kell elvégezni. De mi a helyzet azokkal a munkákkal, ahol kb. 90%-ig vagyunk biztosak, hogy felesleges? Mi a helyzet, ha ezzel a véleményünkkel egyedül vagyunk?

Ezek a vesztes csaták, amit meg kell vívni, mert nem bizonyítható teljesen, hogy vesztesek. Ezek csak kósza érzések, amelyek alapján senkit nem lehet meggyőzni, hogy az erőforrásokat másra fordítsuk. Plána, ha valakinek annyira megbízhatatlanok a megérzései, mint nekem.

A bioinformatikusokra általánosan igaz, hogy a világ összes számítástechnikai kapacitása sem lenne nekik elég, mert bármennyi erőforrást is kapnak, csak még több folyamatot futtatnának, még nagyobb memória igénnyel, több processzor maggal, stb. Ezért, mikor kaptunk egy lehetőséget, hogy ingyen és bérmentve verjünk el 1 csillió dollárt az Azure-on, rábólintottunk. (Ezt csak a hatás kedvéért írtam, a tényleges összes alacsonyabb volt. De tényleg rengeteg pénzről volt szó.)

A Microsoft mostanában erősen lobbizik az akadémiai szférában, hogy a szolgáltatásait minél többen használják. Ezért cukorka helyett hatalmas pénzösszegeket vágnak csoportokhoz, hogy rászoktassák őket az Azure használatára. Az egyik ilyen csoport is, akik tématerveikben dobálóznak az aktuális trendek vezérszavaival (big data, machine learning, stb.), kaptak is 1 csillió zsét meghatározott időre. De nem költötték el, mert nem értettek a cloud használatához.

Mikor már csak két hét volt vissza a határidőből, akkor kezdtek aggódva rohangálni, hogy mit is csináljanak. Ekkor léptünk mi a színre, akiknek ugye nem probléma processzorokat, tárhelyet és memóriát teleszemetelni mindenféle adattal, kutatás címszóval.

Az első hiba a rendszerben az volt, hogy nem mértük fel, mire is van szükségünk. A terv az volt, hogy egy teljes GATK folyamatot futtatunk több száz mintára. Ehhez a mintaszámnak megfelelő mennyiségű 20 magos gépeket kértünk, amelyek reményeink szerint 12 óra alatt emésztik fel a rendelkezésre álló pénzösszeget. Csakhogy 12 óra alatt még senki a csoportból nem futtatott le GATK-t.

A második hiba az volt, hogy nem használtuk ki a felhőben rejlő lehetőségeket. Az összes nagy szolgáltató lehetőséget biztosít, hogy egyszerre felügyeljünk több gépet, van load balancing, virtuális gép képfájlok létrehozása, mozgatása, paraméterezett számítógép indítás, speciális adatbázisok, stb. Ezekből én semmit nem kaptam. Még azt sem engedték meg, hogy magam indítsam a gépeket. Adtak egy mester gépet hatalmas tárhellyel, de szerény teljesítménnyel, és két darab nagy teljesítményű gépet, hogy készítsek egy rendszert, ami megoldja az adatok, programok, stb. utaztatását és a feldolgozás vezérlését. Ha pedig elkészültem a tesztekkel, akkor elindítják nekem az összes igényelt gépet.

Történt még egy apró konfigurálási hiba a részemről, ugyanis a mester gép tárhelyén MBR partíciót hoztam létre, és utána csodálkoztam, miért csak 2TB-ot tudok elérni a 16-ból. Túl sok retro géppel bohóckodom.

Ekkor kezdtem úgy érezni, hogy ez egy vesztes csata lesz, de adtam még 30% a győzelemre. Neki is álltam a "szegény ember Dockerét" megírni. A szkript először yum-al felpakol egy csomó szükséges szoftver komponenst, majd a pip végez telepítéseket. Amint ezek megvannak, a mester gépről scp-vel lemásolja a bioinformatikai programokat, genom fájlokat és egy minta szekvenciáit. Snakemake-el lefut a GATK, majd az eredményeket visszamásolja a mester gépre.

Ez volt a könnyebb része. Hogyan indítsam el a felmásolt szkriptet? Az szóba sem jöhetett, hogy több száz gépre egyenként lépjek be, és adjam ki a parancsokat. Szerencsére az ssh képes parancsot futtatni távoli gépen. Ez bárki ki is próbálhatja egy egyszerű példán:

ssh remote 'ls -la'

Hátránya, hogy amíg a távoli parancs fut, addig fenntartja a kapcsolatot a két gép között, addig nem kapom vissza az irányítást a mester gépen, amíg a parancsoka le nem futnak. Ha több száz gépet akarok vezérelni, akkor mindegyik gépen az elemzés egymás után lesz végrehajtva. Nekem viszont párhuzamos végrehajtás kell.

Ezért készítettem még egy szkriptet, aminek semmi más dolga nem volt, mint nice-al a háttérben futtatni az első szkriptet. A mester gépről ezt kellett csak elindítani. Ez az indítás után azonnal visszaadja a vezérlést nekem. Valami ilyesmi formája van:

nice poormansdocker.sh $1 &

A tesztek ígéretesen haladtak, de azért volt pár probléma. A két tesztelésre adott gép nem volt teljesen ugyan az. Az egyik CentOS volt, a másik Oracle Linux. Bár mindkettő Red Hat alapokon nyugszik, de természetesen teljesen más csomagokat lehetett elérni hozzájuk, például Oracle Linuxon nem lehetett fejlesztői csomagokat telepíteni 3-as Pythonhoz. Ettől nem fordult a Snakemake és nem ment az elemzés.

A másik probléma az idővel volt. A tesztek alapján csak az illesztés 30 óráig futott. Különböző trükkökkel sikerült 27 órára lecsökkenteni, de ez még mindig messze volt az áhított 12 órától, és a leglassabb lépést, a HaplotypeCaller-t még nem is számoltuk. Ekkor már 85% esélyét láttam a kudarcra.

Jött az új terv: csak az illesztési lépést hajtjuk végre, de nem több száz mintára, csak a "legfontosabbakra". Nos, a legfontosabb mintákból 18 hiányzott, és senki nem tudta, hol vannak. Elvesztek valahol a Dropbox-Excel-PhD hallgatók Bermuda-háromszögben.

Az idő közben szorított, mert a határidő közelített, az elemzésre szánt idő viszont hosszabbodott. Végül elindították nekünk a száz gépet. A szkriptet módosítottam, hogy a munka befejeztével kapcsolja ki a gépt. Itt viszont elkövettem a második fiaskót. Abban a hiszemben voltam, hogy ezek a gépek olyanok lesznek, mint amiket tesztelésre kaptam, és nem ellenőriztem ezt. Természetesen nem olyanok voltak. Hiányzott róluk a privát kulcs, amivel elérhetik a mester gépet.

A szkripteket felmásoltam, azok telepítettek mindent, megpróbálkoztak az adatok letöltésével. Ez nem sikerült nekik, ezért búcsút intettek, és lekapcsolták a gépeket. Akkor módosítottam az indítást, hogy ne csak a szkripteket másolja ki, hanem a kulcsokat is, a lekapcsolást pedig kivettem, hogy elkerüljem az újabb bonyodalmakat. (Mivel nem az én kezemben volt az irányítás, ezért emaien kellett kérnem, hogy indítsák újra a gépeket.)

Ez már jól ment. Hanem az előzetes terveket egy újabb fejlemény nehezítette: a száz gép egyszerre rácuppant a mester gépre, és próbálták letölteni az adatokat, amitől persze minden másolás lelassult. De mikor letöltöttek mindent, akkor végre egy kellemes meglepetés is történt. A 30 órás tesztfutásokhoz képest valami csoda folytán az illesztések lementek 8 óra alatt. Hurrá, végre valami jó is történt!

Ezután kicsit összekuszálódtak számomra a történések. Egyik nap még arról volt szó, hogy ezzel a felgyorsult futással az 1 csillió pénznek csak a felét költöttük el, másnap reggelre viszont kiderült, hogy mindent elköltöttük. Nem tiszta, mi is történt. Kicsit furcsa volt, az biztos.

Már csak az adatokat kellett lementeni. Ez sem ment zökkenő mentesen. A BAM fájlok letöltése olyan hosszúra nyúlt, hogy attól féltünk, lekapcsolják a gépeket, mielőtt letölthetnénk az összes mintátt. Ezért különböző gépekre pánik-szerű letöltéseket kezdtünk. Minden további kapcsolat persze lassabb volt, de szerencsére nem lassították a már elindított letöltéseket.

Végül sikerült mindent letölteni, és a gépeket lekapcsolták. A vesztes csata végül nem vereséggel végződött, mert határidőre elköltöttük a pénzt, és a munkával is előrébb jutottunk, de győzelemnek nem könyvelném el, hiszen még rengeteg futtatás van vissza. Az illesztés igazából csak az alapja mindennek.

Az ár egyébként érdekes gondolatokat vetett fel bennem. Alapvetően elég sok pénzbe került, de ha azt nézzük, hogy ezért a pénzért kb. 2 darab Dell munkaállomást lehetne venni, közel hasonló specifikációban (közbeszerzést és egyéb, a kutatók életét színesítő eseményt figyelmen kívül hagyva), akkor már nem olyan durva a helyzet. Mi pedig kaptunk száz számítógépet, igaz, csak két napig. Ha az áramot nem számoljuk költségként, és továbbra is 8 órát adunk egy illesztésre, akkor a két munkaállomással 20 nap alatt végeztünk volna.

Számomra meglepetés volt, hogy a sávszélesség költsége minimális volt. Négy terabyte adatot töltöttünk fel, ez az adat mennyiség utazott a gépek között, végül az eredmény BAM-ok is hasonló nagyságrendben mozogtak, ennek ellenére a költségek fél százalékát tették ki.

A tárhely sem volt vészes. A teljes költség 10%-t emésztette fel. A száz gép 400GB SSD-t használt két napig, a mester gépen pedig 16TB tárhelyet használtunk két hétig.

De ha azt nézzük, hogy ingyen kapunk szuperszámítógép hozzáférést (aminek használatával be fogom fejezni a munkát), akkor elképesztően drága.

Szólj hozzá!

Címkék: rendszergazda cloud computing

A bejegyzés trackback címe:

https://cybernetic.blog.hu/api/trackback/id/tr8015504134

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.
süti beállítások módosítása