Introduksjon til Condor

Konsept

Felles for nesten alle desse er at dei gjer veldig lite tungt arbeid. Dei fleste er arbeidsstasjonar som berre er i bruk når nokon er logga inn og jobbar. Ein del er filtenarar som jobbar hardt om dagen men ikkje har noko å gjere om natta. Denne ledige CPU-krafta er i praksis gratis, og ein ubrukt CPU-syklus kjem aldri attende.

Ved Universitetet jobbar og ein del forskarar og studentar med ei nærast uutømmeleg torv for reknekraft. Dei brukar alle maskinene dei kan få tak i til å rekne på, og er ofte til stor frustrasjon for både IT-ansvarlege og andre som vil bruke maskinene. Desse har og ein tendens til å vere konsentrert på få stadar.

Utfordringa er å finne ein måte slik at forskarane og studentane kan bruke all den ledige CPU-krafta rundt omkring, og syte for at denne CPU-krafta vert rettvist fordelt. Condor er ei løysing på dette.

Condor?

Når ein brukar har eit program han vil køyre, og dette programmet kjem til å bruke ein del CPU over ein periode, sender han det som ein eller fleire jobbar til Condor. Condor samlar inn ein del informasjon om alle jobbane. Til dømes kor mykje minne dei treng, kva operativsystem dei kan køyre under og andre krav til maskiner jobbane kan køyre på.

Samstundes samlar ein anna del av Condor inn informasjon om kva maskiner rundt omkring som har ledig CPU-kraft. Kva som meinast med "ledig" kan eigaren av maskina definere sjølv. I den vanlege Condor-distribusjonen ved UiO er standardvalet at ei maskin er ledig når mindre enn 30% av CPUen vert brukt og ingen har rørt mus eller tastatur eller vore aktive på innloggingar utanifrå dei siste 15 minutta.

Når Condor får inn ein ny jobb eller ei ny ledig maskin, går han gjennom alle jobbane for å sjå om det finst ein jobb som kan køyre på den maskina. Viss jobben treng meir minne enn maskina har, krev ein annan type CPU eller på andre måtar ikkje fyller krava, so prøvar ikkje Condor å køyre jobben der.

Når ei maskin ikkje lenger er definert som ledig, det kan vere fordi nokon har logga inn eller fordi ho fekk noko anna å gjere, so tek Condor eit bilete av jobben og sender han attende inn i systemet. Viss det er ei tilsvarande maskin ledig, vil jobben bli sendt til den maskina med ein gong. Viss ikkje vil biletet bli lagra medan han ventar på ei ny ledig maskin. Når denne dukkar opp vil jobben halde fram frå nøyaktig der han slutta sist.

Meir informasjon

På maskiner med Condor installert, har eg nokre testar og døme under /usit/condor/work/users/sturles/. Les, bli vis og kom i gong i ein fart!

Condor-prosjektet har ei kokebok med enkle døme på korleis ein set saman ein jobb for Condor frå grunnen av.

Prøveprosjektet

Mål

• Condor er stabilt og fungerer
• andre brukarar ikkje merkar at Condor er der når dei er der
• maskinar ikkje på nokon måte vert mindre stabile på grunn av Condor
• opplegget er nokonlunde lett å administrere.

Punkta om maskinstabilitet og at andre brukarar ikkje merkar noko er dei absoulutt viktigaste. Heile poenget med Condor er at han skal gå i det stille på maskiner der nokon jobbar, og ta føre seg når maskina er ledig. Viss brukarar merkar at ting går tregare fordi Condor køyrer ein jobb der, so brukar Condor ei maskin som ikkje er ledig og løyser ikkje problemet godt nok. Viss Condor gjer at ei maskin eller teneste kresjar, er det ei katastrofe.

Vi vil og gjere den testing og utvikling som er naudsynt for å klargjere for utvida bruk seinare, og samle dokumentasjon og erfaringar.

Tekniske løysingar og omfang

Styringsmaskin og "checkpoint-server" er condor.uio.no, alias aqualene.uio.no. Det er ein Linux-boks med to CPUar, 512MB minne og 100Mbit nett. Ho har plass til 20GB med checkpoints og 10GB arbeidsrom til testbrukarane. Det bør halde lenge.

Arbeidsrommet, /usit/condor/work, er montert på alle maskiner som køyrer Condor-jobbar. Ein slik disk er naudsynt for at "vanilje-jobbar" (meir om dette seinare) skal ha ein stad å skrive data til, for det er ikkje sikkert at brukaren sitt heimeområde er montert på maskina som køyrer jobben. Enkelte maskiner vil av tryggingsgrunnar berre køyre "standard-jobbar". På desse er det ikkje naudsynt å montere /usit/condor/work, for alt som programmet gjer av systemkall (t.d open, read, write eller close) vert sendt vidare til og utført av maskina som jobben vart sendt frå. Meir om alt dette kjem seinare.

Det er mogleg å få installert ein "sikker" versjon av Condor. Denne kan berre køyre standard-jobbar, og standard-prosessar kan ikkje snakke med nett eller lokal disk eller gjere nokon andre systemkall (t.d. finne ut kva klokka er) utan å gå via Condor, som svarar med kjent status på submit-maskina eller sender kallet vidare til submit-maskina og hentar svaret derifrå. Den sikre varianten er standard på 186-nettet, og kan skiftast til ved å settje JobUniverse==$(STANDARD) inn som ekstrakrav for START i /etc/condor/condor.config_local. Ta med alt som står bak START i /etc/condor/condor.config og legg til JobUniverse==$(STANDARD)&& før dei andre krava som står der. For å dobbeltsikre, kan ein og leggje til START_VANILLA:False i condor.config_local

Erfaringar til no

Det aller største problemet av alle, er at folk insisterer på å køyre CPU-krevjande skjerm-slitarar når dei ikkje brukar maskina. I tillegg til å vere lite miljøvennlege (blank er betre) og slite ut skjermen, brukar dei nok CPU til at Condor oppfattar maskina som i bruk, og difor ikkje startar nokon jobbar. Dette er ein feil med brukarar; ikkje med Condor.

Condor har eigentleg fungert veldig bra til no, men nokre feil har eg funne. Desse er:

• condor_master, som held kontroll med at alle Condor-prosessane som skal gå går har stansa to gongar på aqualene og teke med seg alle borna sine.
• Det hender ganske ofte at Condor ikkje får med seg at ein jobb faktisk har brukt CPU-tid, og difor ikkje tek bilete av jobben før han vert kasta ut frå ei maskin. Jobben restartar difor frå forrige sjekkpunkt og gjer ein del arbeid på nytt. Dette kan vere plagsamt for jobbar som skriv data til ei fil under køyring, sidan ein del data då vil bli duplisert. Dessutan minskar det effektiviteten til Condor.
• Condor for NT lek minne, men ikkje mykje. Omlag 5MB i veka.
• Condor for NT klarar ikkje å skrive til filer ein sender med jobben, men må bruke separate, midlertidige filer. Desse vert ikkje med attende til submitter-maskina, med unnatak av filene som stdout og stderr går til.
• condor_status under Linux kan ikkje telje. Det er ein reint kosmetisk feil.
• condor_submit bøttar ved den minste feil i submit-fila. Den vanlegaste "minste feil" er at "queue" manglar.

Statusinformasjon

• Status for Condor-maskinene, gitt av condor_status.
• Totale ressursar med i Condor ved UiO, gitt av condor_status -server.
• Ressursar i bruk akkurat no og kven som eig jobbane som køyrer, gitt av condor_status -claimed.
• Prioritet for kvar brukar som har køyrt Condor-jobbar i det siste, gitt av condor_userprio. Høgt tal tyder låg prioritet.

Attendemeldingar og diskusjon

Dette kjem til å bli organisert betre i fleire sider og med meir informasjon etter kvart.