FireWorks-työvuo-työkalu

FireWorks on ilmainen avoimen lähdekoodin työkalu, jolla voidaan määritellä, hallita ja suorittaa työvuoita, joissa on useita vaiheita ja mahdollisesti monimutkaisia riippuvuuksia. Työvuot määritellään joustavasti YAML:lla, JSON:lla tai Python-rajapinnan kautta, ja ne tallennetaan MongoDB-tietokantaan. Tämä sivu kuvaa, miten FireWorks-työvuot määritellään ja suoritetaan CSC:n laskentaympäristössä käyttäen Rahti-konttipilvessä toimivaa MongoDB:tä.

FireWorksin vahvuudet

Helppo asentaa
Voi käsitellä rinnakkaisia (MPI/OpenMP) alitehtäviä
Tukee monimutkaisia työvuoita, 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 alitehtävien on käytettävä samoja resursseja

FireWorksin asentaminen ja MongoDB:n käyttöönotto Rahdissa

FireWorks on helppo asentaa. Suosittelemme käyttämään Tykkyä FireWorksin asentamiseen Singularity-kontin sisälle. Tavallinen pip-asennus pip-containerize-työkalulla riittää; lisää vain rivi fireworks ympäristösi vaatimukset sisältävään req.txt-tiedostoon. Lisäohjeita on Tykkyn dokumentaatiossa.

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, katso Tietokantojen käyttö Rahdissa CSC:n supertietokoneilta. Huomaa, että Rahdin OpenShift-malli ottaa käyttöön 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 FireWorksin asennuksen yhteydessä. Esimerkiksi

# req.txt

fireworks
pymongo==3.10.0

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 suorituskykyongelmien välttämiseksi, sillä Conda tuo mukanaan suuren määrän tiedostoja. Vertailun vuoksi 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ä Tykkyn konttikääretyökalua.

Työvuoiden määrittely ja suorittaminen FireWorksilla

FireWorksin peruskomponentit ovat

LaunchPad (hallinnoi työvuoita ja metadataa)
FireTask (suoritettava laskentatehtävä)
Firework (useiden FireTaskien lista)
Workflow (joukko Fireworkeja sekä niiden riippuvuudet ja metadata)

FireWorker (esimerkiksi kannettava tietokoneesi tai tässä tapauksessa jompikumpi CSC:n supertietokoneista) hakee työvuon LaunchPadista ja suorittaa sen. Jotta FireWorks toimisi oikein CSC:n laskentaympäristössä, sinun on lisäksi määritettävä QueueAdapter, jonka avulla työt suoritetaan jonotusjärjestelmän kautta. Näiden määrittämiseen 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än käyttöön työvuoiden 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 WebSocatin avulla ohjeen Tietokantojen käyttö Rahdissa CSC:n supertietokoneilta mukaisesti. Huomaa, että websocat tulee käynnistää interaktiivisessa istunnossa, jotta kirjautumissolmuja ei kuormiteta. Saatuasi kohdeportin, tietokannan käyttäjätunnuksen ja salasanan suorita lpad init, jotta voit määrittää 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!

Note

Määrityksen yhteydessä WebSocat saattaa antaa varoituksen websocat: Connection reset by peer (os error 104). Tämä varoitus johtuu pienistä ajoitusongelmista, jotka liittyvät Pythonin globaaliin tulkin lukkoon (GIL), ja sen voi turvallisesti jättää huomiotta.

Vaihe 2. QueueAdapterin määrittäminen SLURM-jätystä varten

FireWorksin suorittamiseen eräjonoissa tarvitaan tiedosto my_qadapter.yaml, johon kirjoitetaan jonon parametrit sekä mahdolliset ennen työvuota tai sen jälkeen suoritettavat komennot (esimerkiksi moduulien lataukset ja ympäristömuuttujien viennit). Alla on esimerkki Puhtiin sopivasta my_qadapater.yaml-tiedostosta (muokkaa <>-merkeillä merkityt polut ja sisältö 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>
         export PATH=$PATH:/path/to/websocat
         websocat -b tcp-l:127.0.0.1:<port> wss://websocat-<database name>.rahtiapp.fi -E &
post_rocket: null

Jonoparametrien (resurssipyynnöt, laskutusprojekti) lisäksi QueueAdapter sisältää avaimen rocket_launch, joka määrittää, miten työvuo käynnistetään eräajotyön sisällä. Tätä yksityiskohtaa käsitellään tarkemmin vaiheessa 3. Lisäksi eräjonojärjestelmä (SLURM) määritetään avaimella _fw_q_type, ja ennen työvuota ja/tai sen jälkeen suoritettavat komennot annetaan avaimilla pre_rocket ja post_rocket.

Note

Jotta voit avata TCP-tunnelin Rahdissa olevaan MongoDB:hen laskentasolmulta, websocat tulee käynnistää interaktiivisen istunnon lisäksi myös pre_rocket-osiossa. Tässä voidaan käyttää aiemmin saatua kohdeporttia. Katso lisätietoja ohjeesta Tietokantojen käyttö Rahdissa CSC:n supertietokoneilta.

Kaikki mahdolliset QueueAdapterissa määritettävät SLURM-valitsimet 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 SLURMin käyttämien time- ja partition-avainten sijaan. 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 on annettava tiedostonimet qlaunch- ja rlaunch-komentojen -l- ja -q-valitsimilla (rlaunch-komennolle vain -l). Jos tiedostot eivät ole nykyisessä työhakemistossa, anna täydet polut tai määritä asetushakemisto -c-valitsimella. Hyvä ajatus on myös hyödyntää FW_config.yaml-asetustiedostoa, jossa voidaan määrittää useita oletusparametreja. FireWorksin virallisessa dokumentaatiossa on lisäohjeita FW-asetustiedoston käyttöön.

FireTask kuvaa suoritettavaa alitehtävää, ja useita FireTaskeja yhdistämällä saadaan Fireworkeja ja Workflow’ta. LaunchPadin ja QueueAdapterin tavoin nämä voidaan määrittää YAML-tiedostoilla. Alla on yksinkertainen hello_wf.yaml-esimerkki.

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övuo havainnollistaa sisäänrakennetun ScriptTask-FireTaskin käyttöä MPI-rinnakkaistetun hello_mpi.x-ohjelman suorittamiseen. Suorituksen jälkeen tuloste siirretään käyttäjän kotihakemistoon FileTransferTask-tehtävällä. Riippuvuuksien havainnollistamiseksi työvuo koostuu kahdesta samanlaisesta Fireworkista, joista toinen käynnistetään vasta, kun ensimmäinen on valmistunut. Tämä yhteys määritetään links-osiolla. Katso virallisesta dokumentaatiosta perusteellisempi kuvaus FireWorks-työvuoiden suunnittelusta.

Tämän esimerkkityövuon suorittaminen eräjonojärjestelmän kautta koostuu LaunchPadin nollaamisesta, työvuon YAML-tiedoston lisäämisestä tietokantaan ja lopuksi työvuon jättä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 jättöskriptin FW_submit.script ja jättää 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övuoita, voit käyttää rapidfire-vaihtoehtoa niiden kaikkien suorittamiseen erillisinä eräajotöinä.

Note

rapidfire-tila on suunniteltu siten, että se hakee jatkuvasti LaunchPadista työt, joiden tila on READY. Tämä tila koskee myös töitä, jotka on jo jätetty mutta ovat edelleen jonossa. Tämän seurauksena jonoon voidaan vahingossa jättää liian monta työvuota! Kaksoiskappaleiden välttämiseksi voidaan käyttää valitsimia -m ja --nlaunches, joilla rajoitetaan samanaikaisten jonossa olevien töiden määrää ja jätettävien töiden kokonaismäärää. Katso lisätietoja FireWorksin virallisesta dokumentaatiosta töiden käynnistämisestä jonon kautta.

Vaikka qlaunch suoritetaan peruskomennon rlaunch sijasta, jota normaalisti käytetään ilman eräjonojärjestelmää, rlaunch-komentoa käytetään silti my_qadapter.yaml-tiedoston sisällä kertomaan FireWorksille, miten työvuo tulee suorittaa eräajotyön sisällä. Yllä olevassa tapauksessa käytetään vaihtoehtoa multi 1, jolla käynnistetään yksi rinnakkainen työ käyttäen kaikkia pyydettyjä resursseja. multi-käynnistin on suunniteltu käynnistämään määritetty määrä työntekijöitä, jotka suorittavat FireTaskeja rinnakkain samoilla resurssivaatimuksilla. Jos työntekijöitä määritetään enemmän kuin yksi, kaikkia ScriptTask-tehtävissä annettuja srun-komentoja on muutettava 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ä. Jos esimerkiksi 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 muodossa srun -n 20 --exclusive <my program>. Varo kuitenkin resurssien joutokäyttöä, jos FireTaskit valmistuvat eri aikaan! Lisätietoja rinnakkaisten töiden suorittamisesta FireWorksilla löytyy virallisesta multi job launcher -dokumentaatiosta.

Note

Joka kerta kun srun suoritetaan, luodaan SLURM-työvaihe. Jos työvuosi koostuu suuresta määrästä FireTaskeja, joissa käytetään srun-komentoa, SLURM-loki paisuu, mikä voi heikentää eräjonojä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övuotyö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ä asiakastukeemme, jos et ole varma työvuosi tehokkuudesta.

Vaihe 4. Työvuosi tilan seuranta

Kun olet suorittanut qlaunch-komennon, näet että työsi on jätetty jonoon, ja lpad get_fws -komennolla voit kysyä työvuosi nykyisen tilan. Ennen kuin työ alkaa suorittua, komento näyttää, että ensimmäisen Fireworkin tila on READY, eli valmis suoritettavaksi, kun taas toisen tila on 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ö alkaa, jokaiselle Fireworkille luodaan käynnistyshakemisto, jossa kyseinen työ suoritetaan, ja Fireworkin tila päivitetään vastaavasti tilaan RUNNING. Jos työvuosi siis koostuu kahdesta Fireworkista kuten tässä esimerkissä, oletusarvoisesti 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, 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

Suorituksen aikana tapahtuvat virheet johtavat FIZZLED-tilassa olevaan Fireworkiin, eikä yksikään kaatuneesta työstä riippuva työ voi käynnistyä. FireWorksin virallisessa dokumentaatiossa on perusteellinen kuvaus virheiden ja kaatumisten käsittelystä.