FireWorks
FireWorks on ilmainen avoimen lähdekoodin työkalu useita vaiheita 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 API:n kautta, ja ne tallennetaan MongoDB-tietokantaan. Tällä sivulla kuvataan, miten FireWorks-työnkulkuja määritellään ja suoritetaan CSC:n laskentaympäristössä käyttäen MongoDB:tä, joka toimii Rahti-konttipilvessä.
Jos pohdit vielä työnkulkuja yleisemmällä tasolla tai sitä, mitä työnkulku työkalua kannattaa käyttää, katso myös suurteholaskennan ja työnkulkujen sivumme.
Lisenssi
FireWorks julkaistaan muokatulla GNU GPL -lisenssillä.
FireWorksin vahvuudet
- Helppo asennus
- Voi käsitellä rinnakkaisia (MPI/OpenMP) osatehtäviä
- Tukee monimutkaisia työnkulkuja, joissa on useita toisistaan riippuvia vaiheita
FireWorksin heikkoudet
- Vaatii MongoDB-tietokannan käyttöönoton
- Jyrkkä oppimiskäyrä
- Saattaa tuottaa paljon lokitiedostoja
- Saattaa luoda paljon job stepejä
- 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 vaatimukset sisältävään req.txt-tiedostoon. Lisäohjeita löytyy Tykkyn dokumentaatiosta.
Huomaa, että pip-containerize-työkalun käyttämä Python-versio on ensimmäinen polusta löytyvä Python-suoritettava tiedosto, joten ladatut moduulit vaikuttavat siihen. FireWorks vaatii vähintään Python 3.7:n, joten varmista, että käytössäsi on vähintään tämä versio. Tätä varten voit käyttää pip-containerize-työkalun --slim-valitsinta hyödyntääksesi 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 yksityiskohtaisesti erillisessä ohjeessa, katso Tietokantojen käyttö Rahdissa CSC:n supertietokoneilta. Huomaa, että Rahdin OpenShift-malli asentaa MongoDB-version 3.2, mikä edellyttää, 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 ei enää suosittele Condan suoraa käyttöä supertietokoneillamme, jotta vältetään suuren tiedostomäärän aiheuttamat suorituskykyongelmat. Viitteeksi: FireWorksin Conda-asennus sisältää yli 24000 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 Tykkyn konttikääretyökalulla.
Työnkulkujen määrittely ja suorittaminen FireWorksilla
FireWorksin peruskomponentit ovat
- LaunchPad (hallinnoi työnkulkuja 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önkulun LaunchPadista ja suorittaa sen. Jotta FireWorks toimisi oikein CSC:n laskentaympäristössä, sinun täytyy lisäksi määrittää QueueAdapter, jolla työt suoritetaan 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 API:n käyttöön löytyvät virallisesta FireWorks-dokumentaatiosta.
Ennen LaunchPadin määrittämistä varmista, että olet avannut yhteyden MongoDB-tietokantaasi Rahdissa LoadBalancerin avulla, kuten on kuvattu kohdassa Tietokantojen käyttö Rahdissa CSC:n supertietokoneilta. Saatuasi kohde-IP-osoitteen ja portin sekä tietokannan käyttäjätunnuksen ja salasanan 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 käyttöönotto SLURMin kautta tehtävää ajoa varten
FireWorksin suorittamiseen eräjono järjestelmän kautta 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 Puhdin kanssa yhteensopivasta 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>
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-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 vastakohtana SLURMin käyttämiin time- ja partition-avaimiin. Jos olemassa oleva SLURM-malli ei sovi tarpeisiisi, tutustu viralliseen FireWorks-dokumentaatioon siitä, miten ohjelmoida mukautettuja QueueAdaptereita.
Vaihe 3. Yksinkertaisen FireWorks-työnkulun 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 -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 asettaa useita oletusparametreja. Virallinen FireWorks-dokumentaatio antaa lisäohjeita FW config -tiedoston käyttöön.
FireTask kuvaa suoritettavaa osatehtävää, ja useiden FireTaskien yhdistäminen tuottaa Fireworkeja ja Workfloweja. LaunchPadin ja QueueAdapterin tavoin nämäkin 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ö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 pakotetaan links-osiolla. Katso virallisesta dokumentaatiosta perusteellisempi kuvaus siitä, miten FireWorks-työnkulkuja suunnitellaan.
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
Tiedoston my_qadapter.yaml sisällön perusteella FireWorks luo lähetysskriptin FW_submit.script ja lähettää sen automaattisesti, kun qlaunch suoritetaan. Yllä käytetään singleshot-valitsinta yhden eräajotyön käynnistämiseen. Jos LaunchPadissasi on useita suoritettavaksi valmiita työnkulkuja, voit käyttää rapidfire-valitsinta 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ää ja lähetettävien töiden kokonaismäärää. Katso lisätietoja virallisesta FireWorks-dokumentaatiosta siitä, miten töitä käynnistetään jonon kautta.
Vaikka qlaunch suoritetaan tavallisen rlaunch-komennon sijaan, jota normaalisti käytetään ilman eräjono järjestelmää, rlaunch-komentoa käytetään silti my_qadapter.yaml-tiedoston sisällä ohjaamaan FireWorksia siinä, miten työnkulku tulee suorittaa eräajotyön sisällä. Yllä olevassa tapauksessa valitsinta multi 1 käytetään yhden rinnakkaisen työn käynnistämiseen kaikilla pyydetyillä resursseilla. multi-käynnistin on suunniteltu luomaan 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 todella voivat suorittua rinnakkain saman resurssivarauksen sisällä. Esimerkiksi jos yksi kokonainen Puhdin noodi (40 ydintä) pyydetään kahden samanaikaisen työn (multi 2) suorittamiseen samalla MPI-tehtävien määrällä, 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 suorittamisesta FireWorksilla löytyy virallisesta multi job launcher -dokumentaatiosta.
Note
Joka kerta kun srun suoritetaan, luodaan SLURM job step. 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 sijaan rinnakkaisten töiden käynnistämiseen jonon kautta tai käytä toista työnkulku työkalua, joka pakkaa tehtäväsi yhteen suureen job stepiin. Huomaa myös, että sarjatyöt eivät vaadi srun-komennon käyttöä. Ota rohkeasti yhteyttä asiakastukeemme, jos et ole varma työnkulkusi tehokkuudesta.
Vaihe 4. Työnkulkusi tilan seuranta
Kun olet suorittanut qlaunch-komennon, näet että työsi on lähetetty jonoon, ja komennolla lpad get_fws voit kysyä työnkulkusi 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 launch-hakemisto, jossa kyseinen työ suoritetaan, ja Fireworkin tila päivittyy 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 virallisessa FireWorks-dokumentaatiossa kuvatulla tavalla. Lopuksi onnistuneen suorituksen jälkeen Fireworkin tila merkitään COMPLETED, jolloin 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ä kaatuneesta työstä riippuvia töitä voida käynnistää. Virallinen FireWorks-dokumentaatio sisältää perusteellisen kuvauksen siitä, miten virhetilanteita ja kaatumisia käsitellään.