FireWorks-työvuo-työkalu
FireWorks on ilmainen avoimen lähdekoodin työkalu monivaiheisten ja mahdollisesti monimutkaisia riippuvuuksia sisältävien työnkulkujen määrittelyyn, hallintaan ja suorittamiseen. Työnkulut määritellään joustavasti YAML:lla, JSON:lla tai Python-rajapinnan kautta, ja ne tallennetaan MongoDB-tietokantaan. Tällä sivulla kuvataan, miten FireWorks-työvuoja määritellään ja suoritetaan CSC:n laskentaympäristössä käyttäen Rahti-konttipilvessä ajettavaa MongoDB:tä.
FireWorksin vahvuudet
- Helppo asennus
- Pystyy käsittelemään rinnakkaisia (MPI/OpenMP) osatehtäviä
- Tukee monimutkaisia työnkulkuja, joissa on useita toisistaan riippuvia vaiheita
FireWorksin heikkoudet
- Edellyttää MongoDB-tietokannan käyttöönottoa
- Jyrkkä oppimiskäyrä
- Saattaa tuottaa paljon lokitiedostoja
- Saattaa luoda paljon työvaiheita
- Integroituu Slurmiin, mutta kaikkien osatehtävien on käytettävä identtisiä resursseja
FireWorksin asentaminen ja MongoDB:n käyttöönotto Rahdissa
FireWorks on helppo asentaa. Suosittelemme käyttämään Tykkyä FireWorksin asentamiseen Singularity-konttiin. Tavallinen pip-asennus pip-containerize-työkalulla riittää; lisää vain rivi fireworks ympäristösi riippuvuudet sisältävään req.txt-tiedostoon. Lisäohjeita löytyy Tykyn dokumentaatiosta.
Huomaa, että pip-containerize käyttää sitä Python-versiota, jonka ensimmäinen Python-suoritettava tiedosto löytyy polusta, joten ladatut moduulit vaikuttavat siihen. FireWorks vaatii vähintään Pythonin version 3.7, joten varmista, että käytössäsi on vähintään tämä versio. Tätä varten voit käyttää pip-containerize-komennon --slim-valitsinta, jolloin hyödynnetään valmiiksi rakennettua minimaalista Python-konttia, jossa on paljon uudempi Python-versio kuin järjestelmän oletusversio 3.6.8.
MongoDB-tietokannan käyttöönotto ja siihen yhdistäminen Rahdissa on kuvattu erillisessä ohjeessa, ks. Tietokantojen käyttö Rahdissa CSC:n supertietokoneilta. Huomaa, että Rahdin OpenShift-malli asentaa MongoDB-version 3.2, mikä tarkoittaa, että FireWorksin kanssa käytettävä PyMongo-versio ei voi olla uudempi kuin 3.12. Siksi saatat joutua määrittämään PyMongo-version erikseen req.txt-tiedostossa FireWorksia asentaessasi. Esimerkiksi
Note
Älä asenna FireWorksia Conda-ympäristöön, joka sijaitsee suoraan jaetussa Lustre-tiedostojärjestelmässä. CSC on poistanut käytöstä Condan suoran käytön supertietokoneillamme välttääkseen suorituskykyongelmia, jotka johtuvat Condan tuomasta suuresta tiedostomäärästä. Viitteeksi: FireWorksin Conda-asennus sisältää yli 24 000 tiedostoa, joista suurin osa luetaan aina, kun sovellus käynnistetään. Tämä aiheuttaa käynnistysviiveitä ja heikentää Lustren suorituskykyä kaikille käyttäjille. Tästä huolimatta voit edelleen käyttää Conda-ympäristöjä, mutta vain jos ne on kontitettu. Tämän voi tehdä helposti käyttämällä Tykky-konttikääretyökalua.
Työvuojen määrittely ja suorittaminen FireWorksilla
FireWorksin peruskomponentit ovat
- LaunchPad (hallinnoi työnkulkuja ja metadataa)
- FireTask (suoritettava laskentatehtävä)
- Firework (useista FireTaskeista koostuva lista)
- Workflow (joukko Fireworkeja sekä niiden riippuvuudet ja metadata)
FireWorker (esimerkiksi kannettava tietokoneesi tai tässä tapauksessa jompikumpi CSC:n supertietokoneista) hakee työnkulun LaunchPadista ja suorittaa sen. Jotta FireWorks toimisi oikein CSC:n laskentaympäristössä, sinun täytyy lisäksi määrittää QueueAdapter töiden ajamiseen jonotusjärjestelmän kautta. Näiden määrittelyyn käytettävien tiedostojen sisältö kuvataan alla.
Vaihe 1. LaunchPadin käyttöönotto
Note
Tämä sivu keskittyy YAML-tiedostojen ja FireWorksin komentorivikäyttöliittymä käyttöön työnkulkujen määrittelyssä ja suorittamisessa. Ohjeet FireWorksin Python-rajapinnan käyttöön löytyvät FireWorksin virallisesta dokumentaatiosta.
Ennen LaunchPadin määrittämistä varmista, että olet avannut yhteyden Rahdissa olevaan MongoDB-tietokantaasi LoadBalancerin avulla ohjeen Tietokantojen käyttö Rahdissa CSC:n supertietokoneilta mukaisesti. Kun sinulla on kohde-IP-osoite ja portti sekä tietokannan käyttäjätunnus ja salasana, suorita lpad init määrittääksesi LaunchPadin interaktiivisesti:
$ lpad init
Please supply the following configuration values
(press Enter if you want to accept the defaults)
Enter host parameter. (default: localhost). Example: 'localhost' or 'mongodb+srv://CLUSTERNAME.mongodb.net': localhost
Enter port parameter. (default: 27017). : <target port>
Enter name parameter. (default: fireworks). Database under which to store the fireworks collections: <database name>
Enter username parameter. (default: None). Username for MongoDB authentication: <username>
Enter password parameter. (default: None). Password for MongoDB authentication: <password>
Enter ssl_ca_file parameter. (default: None). Path to any client certificate to be used for Mongodb connection: None
Enter authsource parameter. (default: None). Database used for authentication, if not connection db. e.g., for MongoDB Atlas this is sometimes 'admin'.: None
Configuration written to my_launchpad.yaml!
Vaihe 2. QueueAdapterin määrittäminen SLURM-välityksellä tapahtuvaa ajoa varten
FireWorksin ajamiseen eräjonoissa tarvitaan tiedosto my_qadapter.yaml, johon kirjoitetaan jonoparametrit sekä kaikki ennen työnkulkua tai sen jälkeen suoritettavat komennot (esim. moduulien lataukset, ympäristömuuttujien export-komennot). Alla on esimerkki Puhtin kanssa yhteensopivasta my_qadapater.yaml-tiedostosta (muokkaa polut ja <>-merkeillä merkityt kohdat tarpeen mukaan).
_fw_name: CommonAdapter
_fw_q_type: SLURM
rocket_launch: rlaunch multi 1
nodes: 1
cpus_per_task: 1
ntasks_per_node: 40
mem_per_cpu: 1000
walltime: '00:05:00'
queue: small
account: <billing project>
job_name: example
pre_rocket: |
module load <my module>
post_rocket: null
Jonoparametrien (resurssipyynnöt, laskutusprojekti) lisäksi QueueAdapter sisältää avaimen rocket_launch, joka määrittää, miten työnkulku käynnistetään eräajotyön sisällä. Tätä yksityiskohtaa käsitellään tarkemmin vaiheessa 3. Lisäksi eräjono-järjestelmä (SLURM) määritetään avaimella _fw_q_type, ja ennen työnkulkua ja/tai sen jälkeen suoritettavat komennot annetaan avaimilla pre_rocket ja post_rocket.
Kaikki mahdolliset QueueAdapterissa määritettävät SLURM-liput löytyvät FireWorksin mukana toimitetusta SLURM-mallitiedostosta. Huomaa alaviivojen käyttö väliviivojen sijasta verrattuna tavallisiin SLURM-valitsimiin, esimerkiksi cpus_per_task vs. --cpus-per-task, sekä avaimet walltime ja queue vastakohtana SLURMin käyttämiin time- ja partition-avaimiin. Jos olemassa oleva SLURM-malli ei sovi tarpeisiisi, tutustu FireWorksin viralliseen dokumentaatioon omien QueueAdapterien ohjelmoinnista.
Vaihe 3. Yksinkertaisen FireWorks-työvuon määrittely ja suorittaminen
Note
Jos et käytä oletusnimiä my_launchpad.yaml ja my_qadapter.yaml LaunchPad- ja QueueAdapter-tiedostoille, sinun täytyy määrittää tiedostonimet komentojen qlaunch ja rlaunch valitsimilla -l ja -q (rlaunch-komennolle vain -l). Jos tiedostot eivät ole nykyisessä työhakemistossa, anna täydet polut tai määritä asetushakemisto valitsimella -c. Hyvä käytäntö on myös hyödyntää FW_config.yaml-asetustiedostoa, jossa voidaan määrittää useita oletusparametreja. FireWorksin virallinen dokumentaatio antaa lisäohjeita FW config -tiedoston käyttöön.
FireTask kuvaa suoritettavan osatehtävän, ja useita FireTaskeja yhdistämällä muodostetaan Fireworkeja ja Workflow’ta. Kuten LaunchPad ja QueueAdapter, myös nämä voidaan määrittää YAML-tiedostoilla. Alla on yksinkertainen esimerkki hello_wf.yaml-tiedostosta.
fws:
- fw_id: 1
spec:
_tasks:
- _fw_name: ScriptTask
script: srun /path/to/hello_mpi.x >> first-hello.out
- _fw_name: FileTransferTask
files:
- src: first-hello.out
dest: $HOME/first-hello.out
mode: move
- fw_id: 2
spec:
_tasks:
- _fw_name: ScriptTask
script: srun /path/to/hello_mpi.x >> second-hello.out
- _fw_name: FileTransferTask
files:
- src: second-hello.out
dest: $HOME/second-hello.out
mode: move
links:
1:
- 2
metadata: {}
Tämä yksinkertainen työnkulku havainnollistaa sisäänrakennetun ScriptTask-FireTaskin käyttöä MPI-rinnakkaistetun hello_mpi.x-ohjelman suorittamiseen. Suorituksen päätyttyä tuloste siirretään käyttäjän kotihakemistoon FileTransferTask-tehtävällä. Riippuvuuksien havainnollistamiseksi työnkulku koostuu kahdesta identtisestä Fireworkista, joista toinen käynnistetään vasta ensimmäisen valmistuttua. Tämä yhteys määritetään links-osiolla. Katso virallisesta dokumentaatiosta tarkempi kuvaus FireWorks-työnkulkujen suunnittelusta.
Tämän esimerkkityönkulun suorittaminen eräjono-järjestelmän kautta koostuu LaunchPadin nollaamisesta, työnkulun YAML-tiedoston lisäämisestä tietokantaan ja lopuksi työnkulun lähettämisestä qlaunch-komennolla.
$ lpad reset
Are you sure? This will RESET 1 workflows and all data. (Y/N)
2022-02-14 11:42:59,323 INFO Performing db tune-up
2022-02-14 11:42:59,496 INFO LaunchPad was RESET.
$ lpad add hello_wf.yaml
2022-02-14 11:43:32,144 INFO Added a workflow. id_map: {1: 1, 2: 2}
$ qlaunch singleshot
2022-02-14 11:44:09,835 INFO moving to launch_dir /path/to/launch_dir
2022-02-14 11:44:09,847 INFO submitting queue script
my_qadapter.yaml-tiedoston sisällön perusteella FireWorks luo lähetysskriptin FW_submit.script ja lähettää sen automaattisesti, kun qlaunch suoritetaan. Yllä käytetään singleshot-vaihtoehtoa yhden eräajotyön käynnistämiseen. Jos LaunchPadissasi on useita suoritettavaksi valmiita työnkulkuja, voit käyttää rapidfire-vaihtoehtoa niiden kaikkien suorittamiseen erillisinä eräajotöinä.
Note
rapidfire-tila on suunniteltu siten, että se hakee jatkuvasti LaunchPadista töitä, jotka on merkitty tilaan READY. Tämä tila koskee myös töitä, jotka on jo lähetetty mutta ovat edelleen jonossa. Tämän seurauksena jonoon voidaan vahingossa lähettää liian monta työnkulkua! Kaksoiskappaleiden välttämiseksi voidaan käyttää valitsimia -m ja --nlaunches, joilla rajoitetaan samanaikaisten jonossa olevien töiden määrää sekä lähetettävien töiden kokonaismäärää. Lisätietoja löytyy FireWorksin virallisesta dokumentaatiosta töiden käynnistämisestä jonon kautta.
Vaikka qlaunch suoritetaan tavallisen rlaunch-komennon sijasta, jota normaalisti käytetään ilman eräjono-järjestelmää, rlaunch-komentoa käytetään silti my_qadapter.yaml-tiedoston sisällä kertomaan FireWorksille, miten työnkulku tulee suorittaa eräajotyön sisällä. Yllä olevassa tapauksessa multi 1 -vaihtoehtoa käytetään yhden rinnakkaisen työn käynnistämiseen kaikilla pyydetyillä resursseilla. multi-käynnistin on suunniteltu käynnistämään määritetty määrä workereita, jotka suorittavat FireTaskeja rinnakkain samoilla resurssivaatimuksilla. Jos määritetään useampi kuin yksi worker, minkä tahansa ScriptTask-tehtävän sisällä annetut srun-komennot täytyy muokata käyttämään sopivaa määrää tehtäviä/säikeitä yhdessä --exclusive-valitsimen kanssa, jotta työt voivat todella suorittua rinnakkain saman resurssivarauksen sisällä. Esimerkiksi jos yksi kokonainen Puhti-solmu (40 ydintä) pyydetään kahden samanaikaisen työn (multi 2) suorittamiseen samalla määrällä MPI-tehtäviä, FireTaskien tulisi olla muotoa srun -n 20 --exclusive <my program>. Varo kuitenkin käyttämättömiä resursseja, jos FireTaskit valmistuvat eri aikaan! Lisätietoja rinnakkaisten töiden ajamisesta FireWorksilla löytyy virallisesta multi job launcher -dokumentaatiosta.
Note
Joka kerta kun srun suoritetaan, luodaan SLURM-työvaihe. Jos työnkulkusi koostuu suuresta määrästä FireTaskeja, joissa käytetään srun-komentoa, SLURM-loki paisuu, mikä voi heikentää eräjono-järjestelmän suorituskykyä. Jos tätä ei voi välttää, harkitse orterun-komennon käyttöä srun-komennon sijasta rinnakkaisten töiden käynnistämiseen jonon kautta tai käytä toista työnkulku-työkalua, joka pakkaa tehtäväsi yhteen suureen työvaiheeseen. Huomaa myös, että sarjatyöt eivät vaadi srun-komennon käyttöä. Ota rohkeasti yhteyttä Service Deskiimme, jos et ole varma työnkulkusi tehokkuudesta.
Vaihe 4. Työvuon tilan seuranta
Kun olet suorittanut qlaunch-komennon, näet että työsi on lähetetty jonoon, ja komennolla lpad get_fws voit kysyä työvuosi nykyisen tilan. Ennen kuin työ alkaa suorittua, komento näyttää, että ensimmäinen Firework on merkitty tilaan READY suoritettavaksi, kun taas toinen on tilassa WAITING, koska määritimme FireWorksin olemaan käynnistämättä sitä ennen kuin ensimmäinen on valmistunut.
$ lpad get_fws
[
{
"fw_id": 1,
"created_on": "2022-02-14T09:43:31.941934",
"updated_on": "2022-02-14T09:45:27.533414",
"state": "READY",
"name": "Unnamed FW"
},
{
"fw_id": 2,
"created_on": "2022-02-14T09:43:31.942114",
"updated_on": "2022-02-14T09:43:31.942114",
"name": "Unnamed FW",
"state": "WAITING"
}
]
Kun eräajotyö käynnistyy, jokaiselle Fireworkille luodaan käynnistyshakemisto, jossa kyseinen työ suoritetaan, ja Fireworkin tila päivitetään vastaavasti tilaan RUNNING. Jos työnkulkusi siis koostuu kahdesta Fireworkista kuten tässä esimerkissä, oletuksena luodaan kaksi launcher_*-hakemistoa. Tätä toimintaa voidaan kuitenkin muuttaa ja hallita FireWorksin virallisessa dokumentaatiossa kuvatulla tavalla. Lopuksi onnistuneen suorituksen jälkeen Fireworkin tila merkitään COMPLETED-tilaan, jolloin kaikki siitä riippuvat Fireworkit voidaan käynnistää. Voit varmistaa, että ensimmäinen Firework todella valmistui ennen toista tarkistamalla kotihakemistossasi olevien *-hello.out-tiedostojen aikaleimat.
Note
Ajonaikaiset virheet johtavat FIZZLED-tilassa olevaan Fireworkiin, eikä yksikään kaatuneesta työstä riippuvainen työ voi käynnistyä. FireWorksin virallisessa dokumentaatiossa on perusteellinen kuvaus virheiden ja kaatumisten käsittelystä.