Grafikkprosessering på sky

Transkript

1 Grafikkprosessering på sky Hovedprosjekt, Anvendt Datateknologi Høyskolen i Oslo, avdeling IU Våren 2010 Linda Granstad Magnus B. Sheehan Patrik Nylén Liv Karin Sameien

2 PROSJEKT NR: 13 Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET: Åpen Telefon: Telefaks: HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL: Prosjekt Ymer Grafikkprosessering på sky DATO: ANTALL SIDER: 173 PROSJEKTDELTAKERE: Linda Granstad, Magnus Sheehan, Patrik Nylén, Liv Karin Sameien INTERN VEILEDER: Kyrre Begnum OPPDRAGSGIVER Høgskolen i Oslo KONTAKTPERSON: Kyrre Begnum SAMMENDRAG I dette hovedprosjektet har vi utviklet en grafikkprosesseringsprototype basert på åpen kildekode, som kan sendes ut på en nettsky. Vi vil benytte prototypen for å foreta undersøkelser i forhold til ytelse, forutsigbarhet og kvalitet. Vi vil også se på de kostnadsmessige aspektene ved prototypen, og om løsningen er økonomisk lønnsom. Vi vil gjennom dette prosjektet undersøke om en skybasert tjeneste kan være et reelt alternativ for små og mellomstore bedrifter. 3 STIKKORD: Prototype, grafikkprosessering, nettsky

3 Vi vil rette en stor takk til veilederen vår Kyrre Begnum, som har vist et stort engasjement i vårt prosjekt. Dette prosjektet ville ikke blitt det samme uten deg, og vi vil se tilbake på vårt samarbeid som svært lærerikt og inspirerende. 3

4 Innhold Innhold... 4 Kapittel Innledning... 7 Problemstilling... 9 Kapittel Bakgrunn Nettsky (Cloud Computing) Amazon EC DynDNS Klynge av virtuelle datamaskiner Renderfarm Xen MLN NFS Parallellisering Grafikkprosessering Blender DrQueue Eksisterende løsninger Kapittel Metode Undersøkelsesmetoder Valgt undersøkelsesmetode Kvalitetssikring av testing Design Prosjektdesignets hovedstruktur

5 3.3.2 Konseptuell modell av prototype Kjernespørsmål Testbok Vurdering av prosjektdesignet Kapittel Resultat Implementering av Ymer Ymer Teknisk beskrivelse og fremgangsmåte for Ymer Resultat av tekniske tester Resultat av kostnadsundersøkelser Kapittel Analyse og diskusjon Analyse og diskusjon av testresultater Diskusjon Analyse av kostnadsdimensjonen De juridiske aspektene Evaluering av prosjektet Prosjektets kompleksitet Faglige utfordringer Evaluering av gruppeorganisering Resultatenes betydning Kapittel Konklusjon Oppsummering og konklusjon Fremtidig arbeid Bibliografi Forklaringer Vedlegg Fremdriftsplan Vedlegg Design Designdel A: Prototype

6 Designdel B: Undersøkelse og testing (fase 1, 2, 3 og 4) Designmålene Mål A Prototype Mål C Undersøkelse Vedlegg Script MLN-fil Testscript Vedlegg Testbok Testbokens innhold Vedlegg Tilleggstester Vedlegg Brukermanual for Ymer

7 Kapittel 1 Innledning I dag fokuserer vi ikke nok på verdensfellesskapet. De fleste av oss er mest opptatt av vårt eget, og tenker ikke mye på at små endringer i eget levesett, kan påvirke andres liv og levevilkår. Vi produserer produkter i hovedsak for profitt og eget bruk for øyet, og egoismen råder i mange av valgene man tar som forbruker. Åpen kildekode er et initiativ som fokuserer på å utvikle IT-løsninger transparent, det vil si at man får tilgang til kildekoden og man kan utvikle programvaren videre, om man ønsker det. Dette fellesskapet gjør det mulig å løse komplekse problemstillinger, dele kunnskap, og det bringer mennesker sammen. Som et godt forbilde, kan man si at åpen kildekode i stor grad representerer noe vi i store deler av verden mangler i dag. Kollektiv ånd. I vesten har vi et for høyt forbruk, - høyere enn hva miljøet tåler. I 2007 la FN frem sin siste rapport om hvorvidt menneske skapt C0 2 utslipp har en direkte effekt på den globale oppvarmingen. Konklusjonen var slående, vårt overforbruk vil ha katastrofale konsekvenser for miljøet. Det høye forbruket fører også til massive mengder med avfall, avfall som i de fleste tilfeller ikke kan fornyes. Vi kan anta at man i løpet av en måned i 2010 vil selge omkring 30 millioner hjemme-pcer på verdensbasis. Hvis man plasserer alle maskinene side om side, vil dette tilsvare et areal større enn 420 store fotballbaner. PC-ene kastes ofte ikke fordi de er ødelagte, men de kastes fordi de anses som utdaterte. Bruk og kast mentaliteten som råder gir oss mer og mer avfall, og vi forsøpler uten å tenke så mye på konsekvensene. Forbrukeren har et stadig behov for å fornye datautstyret sitt i tråd med utviklingen av ny teknologi. Dette har ført til at elektronisk avfall i dag er den type avfall som øker mest. Vi står 7

8 foran enorme utfordringer med å nedbryte alt avfallet vi produserer både nå, og ikke minst i fremtiden. Databransjen viser vei, og dens umettelig appetitt for innovasjon vil forhåpentligvis på sikt også skape nye miljøvennlige teknologiske løsninger. Databransjen har de siste 20 årene fullstendig forandret hvordan vi mennesker lever og kommuniserer. På samme måte som internett revolusjonerte kommunikasjonstjenester, så kan nye innovative IT-løsninger være det som med tiden kan hjelpe oss med å løse noe av den store miljøproblematikken. Greenpeace sin klimagruppe anslår at man ved hjelp av innovative IT-løsninger, vil kunne gjøre det mulig å kutte ned på verdens CO 2 utslipp med hele 15 %, innen år En slik grønn innovativ IT-løsning, er desentralisering av ITressurser. Nettskyen har potensial for å kunne bli den framtidige løsningen for både miljø og økonomiske besparelser, og den spås en lys fremtid. Dette er en ny teknologi som bygger på ideén om desentralisering av ressurser. Grunntanken bak dette prinsippet, er å gi forbrukeren datakraft, uten behov for og selv og investere i dyr maskinvare. Forkjemperne for nettskyen poengterer at å jobbe med en slik løsning ikke krever drifting og innkjøp av maskinvare. Siden en nettsky i praksis leverer det forbrukeren etterspør av kraft, så vil man også kunne imøtekomme varierende behov. Skeptikerne derimot, hevder at skybaserte teknologiske løsninger er lite utprøvd, og at de dermed utgjør en reell økonomisk risiko. Hvem som har rett, gjenstår å se, men vi tror små og mellomstore bedrifter som tør utforske ny teknologi, kan ha nytte av nettskyen. De mindre aktørene på markedet kan ha store og uhensiktsmessige utgiftsposter knyttet til innkjøp og drift av maskinvare, og bør derfor begynne tenke mer alternativt. Utfordringen som aktørene innen grafikkproduksjon ofte møter på, er at datagenerert grafikk er en tidkrevende prosess som gir et behov for massiv datakraft. Datamaskinens inntog inn det grafiske miljøet skapte en revolusjon, og man kan anta at nesten all grafisk produksjon generert i verden i dag utføres ved hjelp av datamaskiner. Når man starter opp en bedrift vil man derfor måtte handle inn maskinvare for store summer. Dette gjør at de mindre bedriftene løper en høyere økonomisk risiko, og at de derfor risikerer å tape mye marked til større konkurrenter. For bedrifter som møter på disse utfordringene, kan leie av ressurser fra en nettskytjeneste, være en løsning. Her finnes det flere forskjellige leverandører som leverer et forskjellig spekter av tjenester, og den aktøren som antas å være lengst fremme ved å kunne tilby et relativt bredt spekter av tjenester, er Amazon EC2. 8

9 Vi vil i dette prosjektet undersøke om en skybasert tjeneste kan være et reelt alternativ for mindre bedrifter, som har behov for grafikkprosesseringsverktøy med fokus på ytelse, lønnsomhet, og muligheten å være grønt alternativ. Problemstilling I dette hovedprosjektet vil vi utvikle en grafikkprosesseringsprototype basert på åpen kildekode, som kan sendes ut på en nettsky, for at vi deretter skal kunne utføre følgende: 1. Undersøkelser som kan gjøre oss i stand til å besvare spørsmål relatert til ytelse, forutsigbarhet og kvalitet 2. Undersøkelser om de kostnadsmessige aspektene ved prototypen er økonomisk lønnsom for små og mellomstore bedrifter Presisering: Med spørsmål mener vi en rekke kjernespørsmål vi kommer til å formulere som vil være retningsgivende for utforming av tester, undersøkelser og analyser. Med ytelse mener vi hastigheten på gitte oppgaver Med små og mellomstore bedrifter og mellomstore bedrifter mener vi bedrifter med 1 til 30 ansatte. Med en økonomisk lønnsom løsning, mener vi en løsning som blir billigere enn om bedriften skulle investert i egen maskinvare tilsvarende den skybaserte løsningen. Med forutsigbart mener vi at løsningen skal være pålitelig, ved at en gitt oppgave blir fullført hver gang den blir igangsatt. I tillegg bør gjentagning av samme oppgave vise tilnærmet like resultater hver gang. Kvalitet betyr at grafikkprosesseringsoppgaven blir gjennomført med nøyaktig resultat og at løsningen oppfyller krav til både ytelse og forutsigbarhet. 9

10 Kapittel 2 Bakgrunn For å få bedre innsikt i dette prosjektet og hvordan oppgaven løses, vil vi i dette kapittelet presentere de ulike verktøyene og programvarene som er valgt for gjennomføring av prosjektet. Dette kapittelet er delt inn i 3 hoveddeler. Den første delen er en beskrivelse av Skybasert teknologi (Cloud Computing), der vi vil gå nærmere inn på hva det er og hvordan det virker. Deretter følger en del der vi vil se nærmere på klynger med datamaskiner (Cluster), og hvordan en klynge med maskiner kan fungere som en renderfarm. I denne delen vil vi også se nærmere på de ulike komponentene som er avgjørende for å bygge en fungerende virtuell renderfarm. Til slutt vil vi forklare hva grafikkprosessering er og hvilke grafikkprosesseringsverktøy vi har benyttet i dette prosjektet. 2.1 Nettsky (Cloud Computing) Cloud computing, også kalt nettsky eller skybasert teknologi, er et stadig oftere omtalt IT-begrep. Skybasert teknologi er i praksis det samme som å flytte tradisjonelle IT-tjenester ut på eksterne maskiner eller servere, som er tilgjengelige via internett. En server, også kalt tjener, er en større datamaskin som tilbyr en eller flere tjenester til andre klientdatamaskiner over et datanettverk. Vi har i denne rapporten valgt å bruke ordet server, da denne betegnelsen er oppført i norske leksikon og ordbøker. Figur 2.1 Illustrasjon av nettsky 10

11 Nettskytjenester gjør det mulig å kjøpe fleksible løsninger over internett. Dette kan for eksempel bety at datatjenester og applikasjoner blir tilgjengelige uansett hvor man er, eller fra hvilken som helst enhet man jobber fra. Tjenestene som blir tilbudt gjennom nettskyleverandørene blir ofte delt inn i tre kategorier. Disse er: IaaS (Infrastructure-as-a-Service) IaaS tilbyr virtuelle servere med unike IP adresser og lagringsplass etter behov. Fordelen med denne løsningen er at kunden har full kontroll over sin virtuelle server. Den mest kjente leverandøren av denne tjenesten er Amazon Web Services2. Amazon web services er en underavdeling av selskapet Amazon og ble etablert i Selskapet tilbyr online tjeneseter for websider og klient applikasjoner. De fleste av disse tjenestene er ikke synlige for sluttbruker, men gir funksjonalitet for utviklere. Amazon tar betaling per time tjenesten brukes. Amazons servertype EC2 kan skaleres, og dette betyr at brukeren kan få tilgang til mer kraft om prosjektet utvides. Kjente brukere av tjenesten er Harvard Medical School, Washington Post, Playfish, Stanford AI Lab og Linden lab. PaaS (Platform-as-a-Service) Paas er sett med utviklingsverktøy som er tilgjengelig gjennom tjenesteleverandørens servere, og som utviklere kan bruke for å lage applikasjoner eller programvare. Siden det ikke eksisterer en felles standard, må applikasjonene utvikles og kjøres på tjenesteleverandørens servere innenfor leverandørens rammeverk. En av de mest kjente leverandørene av denne tjenesten er Google App Engine. Google App Engine ble lansert i 2008 som en tjeneste gitt fra Google corporation. Tjenesten gjør det mulig for utviklere og virtualisere applikasjoner over flere servere og datasentre. I motsetning til Amazon sin EC2-server har App Engine infrastruktur for enklere utvikling, men applikasjonene vil bare kunne kjøre på App Engines infrastruktur. Tjenesten er gratis å bruke, det vil si, brukeren får en kvote. Hvis brukeren går over kvotens begrensninger, kan mer datakraft kjøpes. SaaS (Programvare-as-a-Service): SaaS er betegnelsen på alle webbaserte programmer og applikasjoner. Dette er et veldig bredt felt, og omhandler alt fra Hotmail til Twitter. 11

12 2.1.1 Amazon EC2 Amazon EC2 er en populær nettskytjeneste levert av selskapet Amazon Web Services. Tjenesten gir bedrifter, private aktører og forskingsprosjekter muligheten til å leie virtuelle datamaskiner og datanettverk via internett. EC2 baserer seg på Xen virtualiseringsteknologi, og har også et eget grensesnitt som kalles API. Xen virtualisering gjør EC2 fleksibelt, og i teorien kan kunder av EC2 gjenskape et hvilket som helst datasystem de ønsker på nettskyen. Hvis kunden får økt eller redusert behov for datakraft, så kan systemet så skaleres både opp og ned, etter behov. Prisene Amazon EC2 tilbyr følger ganske enkelt prinsippet betal for det du bruker. Timeprisen varierer i forhold til mengde datakraft som brukes, noe som gjør nettskyen svært kostnadseffektiv. Instanstyper Amazon Web Service kaller en virtuell datamaskin for en instans. Under normale forhold vil man definere datakraftbehovet for en instans, ut ifra hva den behøver av kraft for å utføre oppgavene den er tiltenkt å utføre. Amazon EC2 operer derfor med satte instanstyper, som i praksis er maskinkraftmaler som kan tildeles en instans. Dette gjør det enkelt å skalere maskinkraft etter behov. Tabell 2.1 viser en oversikt over hvilke instanstyper EC2 tilbyr sine kunder. ( Instanstype: Størrelse: Minne: CPU: m1.small Liten 1,7 GB 1 EC2 kjerne m1.large Stor 7,5 GB 4 EC2 kjerner m1.xlarge Ekstra stor 15 GB 8 EC2 kjerner m2.xlarge Ekstra stor 17,1 GB 6,5 EC2 kjerner m2.2xlarge Dobbel ekstra stor 34,2 GB 13 EC2 kjerner m2.4xlarge Kvadruppel stor 68,4 GB 26 EC2 kjerner c1.medium Medium 1,7 GB 5 EC2 kjerner c1.xlarge Ekstra stor 7 GB 20 EC2 kjerner Tabell 2.1 De forskjellige instanstypene passer til forkjellige oppgaver. Krever oppgaven mye minne, er en instanstype med mye minne mest egnet. Hvis man derimot har en oppgave som krever lite kraft eller minne, vil en liten standardinstanstype være mer hensiktsmessig. Disse valgmulighetene gir kunden fleksibilitet i forhold til å velge riktig instanstype for den oppgaven de ønsker benytte den til. 12

13 Prisen per time varierer i forhold til instanstype og sone. Med sone, så mener man hvor EC2- nettskyen er lokalisert. Tabell 2.2 viser en oversikt over prisene, i forhold til sone og størrelse på instans. ( Instanstype: US East US West EU West APAC Singapore m1.small $ per time $ per time $ per time $ per time m1.large $ 0.34 per time $ 0.38 per time $ 0.38 per time $ 0.38 per time m1.xlarge $ 0.68 per time $ 0.76 per time $ 0.76 per time $ 0.76 per time m2.xlarge $ 0.50 per time $ 0.57 per time $ 0.57 per time $ 0.57 per time m2.2xlarge $ 1.20 per time $ 1.34 per time $ 1.34 per time $ 1.34 per time m2.4xlarge $ 2.40 per time $ 2.68 per time $ 2.68 per time $ 2.68 per time c1.medium $ 0.17 per time $ 0.19 per time $ 0.19 per time $ 0.19 per time c1.xlarge $ 0.68 per time $ 0.76 per time $ 0.76 per time $ 0.76 per time Tabellen, deler Amazon EC2 inn i fire soner, US East(øst) Virginia, US West(vest) California, EU West(vest) Irland og APAC(stillehavet) Singapore. Den billigste sonen er USA East, mens de andre sonene opererer med samme prisnivå. Tabell 2.2 AMI Dersom man ønsker å opprette en eller flere instanser som benytter datakraft fra Amazon EC2, må man først beskrive instansen. Dette gjøres ved å bruke en ferdig konfigurert image template som tilbys av Amazon EC. Dette er i praksis et filsystem, og man kan velge mellom forskjellige Windows og Unix/Linux distribusjoner. Man kan også lage sitt eget filsystem med egen programvare installert, skreddersydd for å utføre mer spesifikke oppgaver. Disse filsystemene kalles AMIs (Amazon Machine Images), i Amazon EC2 terminologi. For å kunne ta nettskyen i bruk, må filsystemet være lastet opp og registrert som et AMI, med en definert instanstype. Denne oppgaven kan forenkles ved å bruke verktøyet MLN, som automatiserer denne prosessen om man ønsker å bruke klynger av maskiner, fremfor enkeltinstanser. MLN vil bli nærmere beskrevet under punkt IP-adresser Amazon EC2 benytter DHCP (Dynamic Host Configuration Protocol) til tildeling av IP-adresser. Dette er en protokoll som gjør at man ikke manuelt trenger å sette opp en IP-adresse, og som derfor gjør det mulig å flytte instanser mellom nettverk. DHCP deler automatisk ut IP-adresser, en for det interne nettverket, og en offentlig, som gjør det mulig å nå instansen utenfra. Dette betyr i praksis at det ikke er mulig og på forhånd kunne vite hvilken IP-adresse instansen vil få. Amazon tilbyr derfor kundene sine å kjøpe en fast IP-adresse, hvor kunden får opptil fem faste IP-adresser per region. 13

14 Lagring Det er viktig å være klar over at innholdet/de produserte dataene i Amazon EC2- instansene ikke blir lagret på EC2 når de blir slått av. Alt som ikke er hentet ut av data vil gå tapt, og når man starter instansene på nytt vil de i praksis startes opp som helt nye og ubrukte filsystemer. For å kunne omgås dette problemet, tilbyr Amazon elastisk blokklagring (EBS). EBS- tjenesten gir deg permanent lagringsplass på nettskyen, og disse blokkene kan knyttes til de kjørende instansene og brukes som lagringspunkter. EBS kan ikke deles mellom flere instanser, derfor må lagringsplassen følge hver enkelt instans. På lik linje med elastisk IP-adresse, så koster denne tilleggstjenesten en fast sum, per time lagring DynDNS DynDNS er en tjeneste som tilbyr gratis DNS-vertsnavn (eks renderfront.dyndns.org), som peker mot din dynamiske IP-adresse (eks ). Etter registrering av IP-adresse og vertsnavn (se figur 2.2), oppdateres DynDNS raskt, slik at vertsnavnet blir et kallenavn for din IP-adresse. Figur 2.2 viser hvor enkelt det er å knytte en IP-adresse mot et DNS-vertsnavn. Figur 2.2 DynDNS har en TTL (time to live) på 60 sekunder, det vil si at den oppdateres hvert minutt. Man kan også til enhver tid endre IP-adressen som er registrert på vertsnavnet. Dette gjør det mulig for en registrert vert å endre IP-adresse, samtidig som man likevel kan nå verten ved å bruke vertsnavnet. 14

15 Dette vil i praksis for oss bety at man kan gi en Amazon EC2-instans et DynDNS-vertsnavn, slik at det blir mulig å nå den på nettskyen via vertsnavnet, uten at man vet hva den faktiske IP-adressen er. Figur 2.3 DynDNS 2.2 Klynge av virtuelle datamaskiner En klynge av datamaskiner, også kalt cluster på engelsk, er en samling med datamaskiner i et nettverk, som samarbeider parallelt om å løse en oppgave. En slik klynge av datamaskiner kan enten bestå av fysiske maskiner, eller være satt sammen av virtuelle maskiner. Når flere datamaskiner samarbeider for å løse samme oppgave kalles dette parallellisering. Virtualisering Virtualisering er en teknologi som gir oss mulighet til å utnytte datamaskinens ressurser mer effektivt. Et virtualiseringsprogram kan simulere en eller flere komplette datamaskiner der hver datamaskin har en simulert CPU og en simulert disk med minne, men det må alltid være et operativsystem i bunnen som ikke er virtualisert som holder orden på virkelig maskinvare og som kan kjøre virtualiseringsprogramvaren. En slik simulert datamaskin, kalles en virtuell maskin. Dette konseptet ble først utviklet av IBM i 1960-årene for å imøtekomme ønsker om at ulike oppgaver 15

16 skulle kunne kjøres separat og uavhengig på samme maskin. På denne måten kunne virtualisering være med på å øke sikkerheten og fleksibiliteten og samtidig spare strøm og maskinvare. En av fordelene med å benytte virtuelle maskiner i en klynge av datamaskiner, er at skaleringsmulighetene blir enklere. Med skalering mener vi her at vi kan øke totalytelsen i klyngen av datamaskiner ved kun å øke antall virtuelle maskiner. Skalerbarhet innen IT handler stort sett om evnen til å håndtere større datamengder, flere maskiner, mer ytelse, antall brukere, antall funksjoner, hastighet og lignende Renderfarm Render betyr grafikkprosessering. En renderfarm er en klynge med maskiner som jobber sammen i et nettverk, for sammen å utføre en felles grafikkprosesseringsoppgave. Grafikkprosessering er en tung prosess som krever mye datakraft. Dette er beskrevet nærmere i kapittel 2.3 som omhandler grafikkprosessering. En renderfarm kan bestå av en klynge med flere fysiske maskiner eller virtuelle maskiner. Det finnes ikke et godt norsk ord som på en god måte beskriver ordet renderfarm. Vi har derfor i denne oppgaven valgt å beholde renderfarm som ord. Renderfarmens funksjon og nytte Hvilken funksjon har en renderfarm og hvorfor er en den nyttig i grafikkprosesseringssammenheng? Det handler om tid. Tid er som alle vet penger, og for å unngå å sløse med tiden ved å sitte og vente på en grafikkprosess som skal utføres, kan det være lurt og ikke minst innovativt, å benytte ekstra kraft for å fremskynde prosessen. En renderfarm brukes typisk til film, tv og visuelle effekter, noe som ofte betyr store og tunge oppgaver. En renderfarm koster penger, men sammenlignet med hvor mye tid som kan spares, er denne investeringen svært nyttig. Dersom man skal lage en animasjonsfilm, for eksempel på totalt 3000 bilder(frames), kan denne prosessen med en vanlig stasjonær PC ta opptil 8 timer (Intel Core 2,4 GHz) å gjennomføre. Dersom man derimot bruker en renderfarm for ekstra datakraft, kan man redusere grafikkprosesseringstiden til i underkant av 3 minutter. Det er her en renderfarm viser fram sin enorme styrke. Programvaren for en renderfarm har en typisk klient-server arkitektur. For å håndtere større maskinklynger, må man ha et køhåndteringsprogram som kan distribuere prosesser til de forskjellige prosessorene, i tillegg til å omprioritere og optimalisere bruken av maskinene i 16

17 renderfarmen. I en renderfarm der klyngen av maskiner består av virtuelle maskiner, kalles gjerne disse maskinene for noder. Renderfarmprosjekt I dette prosjektet vil vi lage renderfarmprosjekter som vi skal sende ut på Amazon EC2. Fordi man kan ha flere renderfarmer, med for eksempel forskjellig antall noder, vil vi i denne rapporten referere til en renderfarm som et renderfarmprosjekt. Fordi vi har brukt flere renderfarmprosjekter underveis i dette prosjektet, vil renderfarmene i tillegg kunne ha et navn for versjon, for eksempel renderfarmprosjekt med 2 slavenoder av instanstype c1.xlarge. Dette vil vi forklare mer detaljert i kapittel MLN Xen Xen hypervisor er en virtualiseringsmonitor for x86m x86_64, ARM, IA64 og andre CPU-arkitekturer. Programmet er basert på åpen kildekode, og gjør det mulig å kjøre flere separate operativsystemer på en og samme maskinvare. Xen.org-samfunnet utvikler og vedlikeholder Xen hypervisor som en gratisløsning lisensiert under GNU General Public Licence. Xen var opprinnelig et forskningsprosjekt ledet av Ian Pratt, på Cambridge University i England. Den første offisielle versjonen ble lansert i I oktober 2007 kjøpte Citrix Systems XenSource Inc, og flyttet prosjektet til I oktober 2009 annonserte Citrix at deres nå kommersielle Xen applikasjoner, ville bli en åpen kildekodebasert applikasjon og gjort kostnadsfritt tilgjengelig for allmennheten. Simon Crosby, teknisk leder av Citrix virtualisering og administrasjonsavdeling sa: «XenServer er 100 % gratis, og har i tillegg fullstendig åpen kildekode. Vi har ingen profitt her». Hvordan fungerer Xen? Xen har en struktur med Xen hypervisor som det laveste og mest privilegerte lag. Den er ansvarlig for CPU-fordeling og minnedeling av det varierende antallet virtuelle maskiner som kjører på maskinvaren. Hypervisoren ikke bare abstraherer maskinvaren for virtuelle maskiner, men kontrollerer også igangsetting/kjøring av de virtuelle maskinene fordi de deler prosessmiljø. Den har ingen kjennskap til nettverk, eksterne lagringsenheter, video eller andre vanlige I/O-funksjoner man finner i et datasystem. 17

18 En datamaskin som kjører Xen hypervisor inneholder tre komponenter. Dette er: Xen hypervisor. Domain 0 Guest (Dom0), som den mest privilegerte gjest som kjører på toppen av hypervisoren med direkte maskinvaretilgang. Multi Domain Guests (DomU), uprivilegerte gjester som kjører på hypervisoren. Xen hypervisor kjører direkte på maskinvaren og blir grensesnittet for alle spørringer fra maskinen, som for eksempel CPU, I/O. Den fungerer også som disk for gjesteoperativsystemene. Figur 2.4 Xen Dom0 Guest, videre referert til som Dom0, starter opp automatisk når hypervisoren startes opp. Dom0 kan kjøre alle operativsystemer bortsett fra Windows. Dom0 har unike tilgangsprivilegier til Xen hypervisor som ikke er allokert til noen andre Dom Guests. Disse privilegiene gjør det mulig for den å håndtere alle aspekter av Domain Guests som å starte, stoppe, I/O spørringer, osv. En systemadministrator kan logge seg på Dom0 og administrere hele systemet. Dom Guests, referert til som DomU blir operert og kontrollert av Dom0. DomU opererer selvstendig i systemet. Disse gjestesystemene blir enten kjørt med spesialmodifisert operativsystem, referert til som paravisualiserte eller umodifiserte operativsystemer, som leverer spesielle virtualiseringsmaskinvare (Intel VT og AMD-V) referert til som HVM (Hardware Virtual Machine). - Virtualisering er et begrep brukt til å beskrive virtualiseringsteknikker som tillater operativsystemer å være oppmerksom på at det kjører på en hypervisor og ikke en basismaskinvare. Operativsystemet må være modifiser til å tilpasse seg det å kjøre på en hypervisor i stedet for vanlig maskinvare. - HVM er et begrep brukt til å beskrive et operativsystem som kjører i et virtualisert miljø uforandret og uoppmerksom på at den ikke kjører direkte på maskinvaren. Spesielt tilpasset maskinvare trengs for å kunne utføre dette, derav begrepet HVM. 18

19 2.2.3 MLN MLN (Manage Large Networks) er et program som brukes til å lage komplette nettverk av virtuelle maskiner, basert på Xen eller User-Mode-Linux, fra en enkelt konfigurasjonsfil. Formålet er å forenkle konfigurering og administrering av virtuelle nettverk. MLN er basert på åpen kildekode og er utviklet av Kyrre Begnum. MLN er et komplekst program som tilbyr et bredt spekter av funksjonalitet: MLN gjør det mulig å ha flere separate nettverk/renderfarmprosjekter samtidig, og kan også sette disse sammen til større nettverk. MLN tilbyr plugins for blant annet Amazon EC2 og DynDNS, hvilket gjør det mulig å sende et MLN-nettverk på en nettsky, samt spore det med DynDNS. MLN bygger og konfigurerer filsystemmaler basert på dets beskrivende og enkle programmeringsspråk, og lagrer dem systematisk. Det genererer også start og stoppscript for hver virtuelle vert, og muliggjør å administrere et kjørende virtuelt nettverk ved å kunne stoppe individuelle virtuelle maskiner, og starte dem igjen. MLN-filsystemmal Med MLN kan vi opprette filer som hver og en representerer en mal for et prosjekt. Et slikt prosjekt er i praksis en klynge av virtuelle maskiner, og i dette prosjektet vil vi referere til disse som renderfarmprosjekter. MLN har et konfigureringsspråk som gjør det mulig å tilpasse innholdet i disse filene etter hvordan renderfarmen skal se ut og fungere. Disse konfigurasjonene gjøres i såkalte blokker, som kan minne om et deklarerende programmeringsspråk. Hver konfigurasjon er navngitt, og man kan man definere disse blokkene og tilpasse renderfarmprosjektet, alt etter ønske. Disse blokkene kan for eksempel definere hvilken sone og instanstype man ønsker benytte på Amazon EC2, og informasjon som er nødvendig for at DynDNS-pluginet skal fungere. Når en MLN-filsystemmal for et renderfarmprosjekt er ferdig konfigurert, så kan det bygges. Å bygge et renderfarmprosjekt er i praksis det samme som å sende det til nettskyen. 19

20 I figur 2.5 vises et eksempel på hvordan man kan konfigurer blokken som gjelder for Amazon EC2. Figur 2.5 EC2-blokken Fordeler med MLN MLN gir deg mange praktiske fordeler. Man forenkler logistikken om man f. eks har flere maskiner kjørende på samme PC, noe som gjør det enklere å teste og utvikle på flere maskiner på for eksempel en og samme PC. Man kan også spare både tid og penger fordi man ikke trenger å fornye maskinvare eller bruke mye tid på vedlikehold som installering osv. På en virtuell maskin kan man enkelt bytte "image" (filsystem) eller endre antall instanser i nettverket. I lærings- eller forskningssammenheng, trenger man ofte flere maskiner for å gjennomføre et eksperiment, en oppgave eller et kurs. MLN ble laget for dette formålet: En rask og effektiv måte å konfigurere, bygge, gjenopprette og dele komplekse nettverk på. MLN er skrevet med tanke på langtidsbruk og er tiltenkt brukt i blant annet utdanningsinstitusjoner. I denne sammenheng må det være mulig å administrere mange virtuelle nettverk over en lang periode av tid, uten store vansker. Studenter skal også kunne klare bygge deres egne nettverk som testmiljøer hvor de kan lære UNIX systemadministrasjon. MLN kan også brukes til å lage testmiljøer hvor systemadministratorer kan undersøke nye konfigurasjoner, og det kan også brukes som en del av et produksjonsnettverk for separate tjenester i separate instanser. 20

21 Figur 2.6 MLN gjør det enkelt å migrere et renderfarmprosjekt frem og tilbake til Amazon EC NFS NFS, (Network File System) nettverksprotokoll ble opprinnelig utviklet av Sun Microsystems i Programmet er basert på åpen kildekode og kan lastes ned kostnadsfritt. NFS gjør det mulig for to eller flere klienter å dele ressurser på en måte som gjør de like lett tilgjengelig som de lokale enhetene. I praksis kan dette gjøres på denne måten: Man bruker mount -kommandoen til å koble enhetene sammen via NFS mot en bestemt mappe i filtreet, for eksempel på denne måten: pc#~: mount t nfs :/mnt /mnt Kommandoen kobler klienten man jobber fra, til med tjeneren i mnt-mappen. De skal nå kunne se hverandres filer i denne mappen. For å koble seg fra brukes kommandoen: pc#~: umount /mnt 21

22 Figur 2.7 NFS, delt lagring Det finnes flere versjoner av NFS. De som brukes i dag er i hovedsak NFS-kernel-server og NFS-userserver. Kernel versjonen er raskere og mer pålitelig enn user-versjonen. User-versjonen blir til sin fordel, kjørt som en deamon, og krever ikke støtte for kernel. Dette betyr i praksis at den kjøres som et program i bakgrunnen. Hvis man er uheldig og NFS går ned, av en eller annen årsak, så vil det ikke påvirke hele systemet, men det vil bare være en prosess som dør. Så man kan på mange måter si at den ene versjonen taler for hurtighet, mens den andre taler for sikkerhet Parallellisering Parallellisering er et prinsipp oftest brukt i sammenheng med store datautregninger. Under en parallellisert utregning, vil utregningen kuttes ned i mindre oppgaver og fordeles til en klynge av maskiner. Klyngen løser så den oppdelte regneoppgaven parallelt. Ville man utført samme utregning med kun en datamaskin, og denne datamaskinen hadde hatt samme kraft som klyngen totalt, så ville denne datamaskinen brukt lenger tid på samme utregning. Dette fordi en enkeltmaskin må løse regneoppgaven i en gitt sekvens, og dette fører til en veldig begrenset ytelse. Parallellisering i praksis Et område parallelliseringsprinsippet vil ha en stor nytte, er i en skalerbar klynge. Når klyngen øker i størrelse blir utregningen delt opp i enda mindre biter. Dette fører til at kalkuleringstiden vil minske forhold til klyngen størrelse. Vi kan regne ut hvor stor hastigheten øker med følgende formel: 22

23 Formelen kan forklares med at p er antallet prosessorer(maskiner) T 1 er tiden en maskin bruker på og utføre prosessen. T p er tiden den parallelle prosessen tar med antall prosessorer. S p er hurtighetsøkningen den parallelle utregningen har. Eksempel på utregningen: 5000sek/1000sek = 5. Systemet er fem ganger raskere enn tiden en maskin bruker på å gjennomføre utregningen. Dette vil i teorien si at et system som benytter seg av parallellisert teknologi ikke har noen begrensing på hvor høy ytelse som kan oppnås. Dessverre vil ikke teorien utføres i praksis. Alle systemer som benytter seg parallellisering vil tilslutt flate ut, hvorpå klyngen ikke vil klare å gjennomføre den teoretiske hastighetsøkningen. Amdahls argument Amdahls argument, oppkalt etter fysikeren Gene Amdahl, (Kilde:publisert, 1960) hevder Amdahl at ingen utregning kan parallelliseres 100 %. Konsekvensen av dette er at ytelsen i et parallellisert system tilslutt vil flate ut. Forklaringen Amdahl gir, er at enkelte deler av en utregning ikke kan kuttes ned i mindre deler. Klyngen må derfor vente på at utregningssekvensen er ferdig før de kan fortsette, noe som svekker systemets hastighet. 2.3 Grafikkprosessering Datagrafikk eller grafikkprosessering er betegnelsen på et bilde (grafikk) generert eller modifisert med en datamaskin. Begrepet oppstod på 1960-tallet rundt IT-student miljøet i USA som også lagde de første grafiske programmene. På 70 tallet startet flere Amerikanske universiteter, med MIT i spissen, å undervise i datagrafikk som eget fagfelt. Vi kan anta at i dag blir nesten all grafisk produksjon (foto, video plakater osv) prosessert med en datamaskin i minst et ledd. Grunnprinsippet bak datagrafikk går ut på at datamaskinen generer et rutenett (x og y akse) med små celler som kalles piksler. Jo flere celler, jo høyere kvalitet. Datamaskinen sorterer så pikslene i et mønster, med posisjon og farge som vil gjenskape grafikken på skjerm eller trykk. I et tradisjonelt todimensjonalt bilde (foto eller trykk) kan man sortere pikslene etter to prinsipper: rastermetoden(bitmap) eller vektormetoden. 23

24 Raster metoden Innen rastergrafikk (bitmap) genereres, som nevnt ovenfor, et rutenett som blir sortert i en algoritme i forhold til farge og pikselposisjon. Raster grafikk er spesielt godt egnet til fotorealistiske bilder fordi man har tilgang til uendelige farge og plasserings kombinasjoner. Men man kan ikke skalere uten og miste vesentlig kvalitet av bildet. Figur 2.8 Skaleringseksempel rastergrafikk Vektor metoden I vektorgrafikk genereres grafikken gjennom geometriske objekter. Dette gjør at vektorgrafikk kan skaleres uten tap av kvalitet, men har mindre farge og plasserings kombinasjoner. Dette fordi i motsetning til rastergrafikk lagrer vektorgrafikk linjene og formene som gjør opp bildet med matematiske formler. Feltene blir så fylt inn med fargeinformasjonen som blir gitt av dataprogrammet. Disse to modellene brukes i dag til nesten all produksjon av bilder. Ved mer kompleks bildegenerering, hvor man ønsker å skape en tredimensjonal modell i rom, kombinerer man begge teknikkene for å oppnå resultatet man ønsker. En tredimensjonal modell skapes i to faser. I første fase genereres en modell ved hjelp av vektor genererte objekter som plasseres på en x,y og z akse. Andre fase bruker man rasterprosessen for og generere et så naturtro bilde som mulig. Etter rasteringsprosessen blir bildet som oftest todimensjonalt og kan ikke skaleres uten tapt kvalitet. Figur 2.9 Enkel presentasjon av 3D 24

25 Animasjon I animasjoner er det omkring 30 bilder per sekund. Et bilde består av røde, grønne og blå punkter som skal flytte plassering 30 ganger i sekundet. Ved 3D-animasjon, benyttes i tillegg en veldig komplisert utregning for å få fram strukturer, skygge og lignende. Dette gjøres for å få fram mest mulig naturlig bilde eller bevegelse. Vann beveger seg for eksempel annerledes enn ild. Å prosessere all denne informasjonen er en veldig avansert operasjon som krever mye datakraft Blender Blender er et avansert verktøy for å lage 3D grafikk. Blender er en gratis programvare basert på åpen kildekode, utviklet og eies av stiftelsen The Blender Foundation. Det gis ut under GNU General Public License som er en vanlig lisens for gratis programvare. Figur 2.10 Eksempel på muligheter med Blender 2.49b Blender er under stadig utvikling, og er i dag et verktøy som fint kan konkurrere med de større aktørene i markedet som for eksempel Maya og 3DS Max. Blender 2.49b er siste versjon av programmet og støtter alle de største operativsystemene som f.eks. Windows (2000/XP/Vista/7), 25

26 Linux og MAC OS X. Blender tilbyr avanserte verktøy for 3D-modellering, animasjon og grafikkprosesseringsprogram DrQueue DrQueue er et køhåndteringsprogram for renderfarmer. DrQueue er en programvare basert på åpen kildekode, og er lisensiert under GNU (General Public License) GPL Versjon 3. Som beskrevet i kapittel 2.3, handler grafikkprosessering om å prosessere mengder av informasjon om punkter, farger, struktur og skygge, alt satt sammen til et bilde, for at bildet deretter blir satt sammen med andre bilder slik at de sammen blir en sekvens av bilder som følger hverandre. Dette er en tung og avansert prosess. En grafikkprosesseringsjobb i DrQueue er satt sammen av flere oppgaver. Den viktigste funksjonen til programmer som styrer renderfarmer, er å administrere køen av grafikkprosesseringsoppgaver og fordele oppgavene mellom alle nodene i renderfarmen. DrQueue fordeler oppgaver på bildebasis. Dette betyr at et bilde er en grafikkprosesseringsoppgave som skal fordeles til en node. DrQueue består i hovedsak av tre hovedverktøy. Disse er mester, slave og drqman. Både mester og slave er en node. Oppgavene i en grafikkprosesseringsjobb blir fordelt ut til slavenodene av mesternoden. Mesternoden fungerer som et sentralt knytepunkt i renderfarmen, der alle oppgavene er lagret. Slavenodene utfører oppgavene og rapporterer jevnlig sin status tilbake til mesternoden. DrQman er grensesnittet som brukes for å sette i gang og kontrollere jobbene som utføres. Dette kan være for eksempel å omprioritere jobber eller stoppe dem. DrQueue er kompatibel med flere av ulike grafikkprogram, som for eksempel Maya og Blender. 2.4 Eksisterende løsninger Det finnes per dags dato flere leverandører som tilbyr ulike løsninger som kan ligne på den prototypen vi vil forsøke å lage i dette prosjektet. Mange har innsett at grafikkprosesseringstjenester kan være lønnsomme. For å nevne noen leverandører, så finnes det blant annet følgende: Render Rocket, Rebus Render, ResPower Super og Renderfarm.fi. Det er få variasjoner innefor disse 26

27 tjenestene, men de har alle samme formål, nemlig å levere en grafikkprosesseringstjeneste i utbytte mot penger. Leverandørene tilbyr i tillegg også ferdige programapplikasjoner som er kompatibelt med de fleste store animasjonsprogrammene, for eksempel Maya 3D Studio Max. Dette gjør at løsningene blir veldig anvendbare, og det merkes tydelig at det finnes et stort marked for disse typer tjenester. En av de mest interessante løsningene rundt grafikkprosesseringstjenester er i dag tjenesten vswarm. vswarm er en tjeneste som er mest brukt av små bedrifter, frilansere og hobbyentusiaster. Dette er en brukergruppe vi kan anta ikke har samme tilgang til en stor serverpark, på samme måte som større bedrifter og foretak gjerne har, men som likevel har hatt behov for å prosessere grafikk hurtigere enn det lar seg gjøre med en vanlig hjemmedatamaskin. Løsningen på dette problemet blir å bruke tjenesten vswarm, spesielt siden denne tjenesten er gratis. Ideen med vswarm er at alle som er med har mulighet til å dele sin personlige maskinvare, på samme måte som et peer-to-peer nettverk. Dette innbærer at brukerne selv kan bestemme hvor mye av sin datakraft de vil dele med nettverket. Systemer holder oversikt over hvor mye datakraft du deler i nettverket, som videre legger føring for hvor mye datakraft du får tildelt når du selv har behov for å benytte deg av tjenesten. Deler man mye datakraft, får man mye datakraft igjen. vswarm beviser med dette at det er mulig og kutte ned grafikkutregningstiden ved å fordele oppgaven mellom mange hjemmedatamaskiner i stedet for eksempel for en renderfarm. Selv om det i dag finnes flere ulike løsninger for grafikkprosessering på en nettsky, har vi gjennom våre undersøkelser, ikke klart å finne en løsning som har de samme komponentene som vi planlegger å benytte i vårt prosjekt. De eksisterende løsningene er stort sett lukkede løsninger, med lite tilgjengelig dokumentasjon på brukte komponenter. Dette gjør at vi kan hevde at vårt forsøk med å utvikle en prototype basert på åpen kildekode, der komponentene presentert i dette prosjektet er benyttet, ikke har vært gjort tidligere. 27

28 Kapittel 3 Metode I dette kapittelet vil vi presentere fremgangsmåten for dette prosjektet, og se på hvilke undersøkelsesmetoder vi vil benytte for å undersøke om en skybasert løsning kan imøtekomme krav om ytelse, forutsigbarhet og kvalitet, samtidig som det er økonomisk bærekraftig for små og mellomstore bedrifter. Vi vil deretter gi en mer detaljert beskrive av designet av prosjektet, hvordan vi planlegger å gjennomføre undersøkelsene og se på dette i forhold til hvilke krav vi har satt i kravspesifikasjonen. 3.2 Undersøkelsesmetoder For å finne ut hvilken type forskningsmetodikk som egner seg best til dette prosjektet, var det først og fremst viktig å finne ut hvilken type forskning dette prosjektet ville bli kategorisert under. Prosjektet stod mellom tre ulike former for forskning, da prosjektet både kan sees på som behovsmotivert forskning, utviklingsarbeid og som et utredningsarbeid. Etter vår vurdering mener vi at prosjektet best egner seg som et utredningsarbeid. Dette mener vi fordi utvikling av prototypen ikke er et hovedmål i seg selv, men et delmål som skal fungere som et hjelpemiddel for å utføre testing og undersøkelser for å nå ønskede resultat i utredningen. Formen utredningsarbeid passer også best i forhold til problemstillingen. 28

29 Utredningsarbeid I et utredingsarbeid utføres en objektiv sammenstilling av tidligere kjente kunnskaper og konklusjoner. Dette vil bli en utfordring i dette prosjektet, da det ikke eksisterer dokumentasjon på lignende løsninger. Utredningsarbeidet starter med innhenting av bakgrunnsinformasjon og etterfølges deretter av at det oppstår et kunnskapsbehov. Denne kunnskapen trenger forankring i enten en hypotese eller, som i vårt tilfelle en problemstilling. Det er viktig å poengtere at en undersøkelse ikke er styrt av en subjektiv overbevising som skal påvises eller bekreftes. I stedet skal undersøkelsen styres av informasjonen som er relevant for å besvare problemstillingen. Resultatene av utredingsarbeidet skal gi relevant informasjon for besvaring av problemstillingen. I vårt tilfelle er det et spørsmål om enten å velge en empirisk-atomistisk eller en empirisksamlingsmetode. Disse vil bli beskrevet i kapittel I et utredningsarbeid, er det viktig å velge en metode som ikke vil påvirke og legge føringer for hvilke deler av problemstillingen som blir besvart. Utrederne må ha en klar problemstilling å basere forskningen på. En utredning som mangler et slikt styrende formål eller problemstilling, er ikke en utredning. Det er også viktig for dette formålet, at problemstillingen skal være tydelig. Hvis ikke, kan det settes spørsmålstegn ved utredningen. For å forklare det enkelt, krever den logiske strukturen i et utredningsarbeid at den styres av minst ett mål eller en klar og tydelig problemstilling Valgt undersøkelsesmetode For å samle informasjonen, stod valget mellom empirisk-holistisk og empirisk-atomistisk metode. For å redegjøre for vårt valg av metode, vil vi presentere fordelene, ulempene og forskjellene mellom disse to metodene. Empirisk-atomistisk (kvantitative metoder) Kvantitativ metode er basert på at man som forsker skal oppnå målbare data. Disse dataene er vanligvis samlet inn gjennom ulike spørreundersøkelser. Ved denne metoden er resultatene det viktigste, og ikke en inngående forståelse av hvorfor det ble slik. Som nevnt ovenfor, er det de målbare resultatene som står i fokus. 29

30 For å gi en bedre forklaring på hva en kvantitativ studie er, vil vi vise dette gjennom et eksempel: La oss si at et firma, gjennom en spørreundersøkelse, ønsker å finne ut følgende: Hvor mange elever spiser kebab hver dag ved en gitt skole? For å undersøke dette, er det hensiktsmessig å benytte en tilfeldig utvalgt gruppe elever, og be dem besvare et spørreskjema. Elevene mottar de samme forutbestemte spørsmålene, i samme forutbestemte rekkefølge for å skape et objektivt testmiljø. Resultatene av denne undersøkelsen må bli i form av målbare tall. Dette fordi det er tall som best besvarer spørsmålet som var hensikten med undersøkelsen, nemlig hvor mange elever som spiser kebab på den gitte skolen. I Prosjekt Ymer vil vi utvikle en prototype som vi skal undersøke og utføre tester mot, slik at vi på den måten skal kunne besvare problemstillingen gitt i dette prosjektet. Hensikten med undersøkelsene er å finne resultater som kan gjøre at vi kan dra slutninger i forhold til prototypens kvalitet, ytelse og forutsigbarhet, noe som er en viktig del av problemstillingen. Disse resultatene kommer i hovedsak til å bestå av variasjoner i form av tid, kvalitet og framfor alt kostnad. En vanlig definisjon er at alle typer resultat som resulterer i sifre, er beskrevet som kvantitative data. Resultater som ikke består av sifre, for eksempel tekst, bilder eller ustrukturerte observasjoner, benevnes som kvalitative data. Den kvantitative metoden er best egnet for større studier der det inngår mange tester eller der en større testgruppe inngår. Vi kan oppsummere den kvantitative metoden på følgende måte: Denne metoden er en samlebetegnelse for en systematisk tilnærming, hvor forskeren samler empiriske (kvantitative) data, som blir oppsummert i statistisk form, og analyseres gjennom målbare data. Empirisk-holistisk (kvalitativ metode) Den kvalitative metoden er en mer inngående undersøkelsesmetode enn kvantitative metode. Dersom vi bruker overnevnte eksempel om elevers kebabvaner, ville vi ved ev kvalitativ undersøkelsesmetode, fått andre resultater. Gjennom den kvalitative metoden hadde vi ikke antallet studenter som spiste kebab vært det sentrale. I stedet hadde vi for eksempel fått informasjon om hvilke tilbehør elevene anså som mest velsmakende, og hva elevene synes om kebab. Her er det mindre fokus på målbare resultater, men i stedet mer på menneskelige aspekter, dens innhold og dens betydning. Ved kvalitativ metode er ofte forskeren selv en del av den virkeligheten som skal undersøkes og analyseres. Dette medfører ofte til at datainnsamlingen og analysen skjer samtidig. Dette betyr at en 30

31 forsker for eksempel kan observere sitt intervjuobjekt, og gjøre tolkninger av observasjonene, samtidig som forskeren foretar intervjuet. Dette gir forskere en sjanse til å tolke resultatet av undersøkelsen og skape en forståelse for betydningen av denne. I motsetning til kvantitative metoder så har den kvalitative metode en tendens til å involvere mindre populasjoner. Den kvalitative metoden er nøkkelbegrepet observasjon. Å observere, å se og dokumentere hvordan systemet fungerer, hvordan den reagerer i ulike situasjoner, og ikke minst hvordan resultatene oppnås. Utvalgte innsamlingsmetoder Vi mener vårt prosjekt kategoriseres under den kvantitative metoden, da vi som forskere vil være utbyttbare. Med dette mener vi at andre forskere skal kunne gjennomføre det samme prosjektet med de samme undersøkelsene som vi kommer til å benytte i dette prosjektet. Prosjektet er veldig målrettet, forskningsområdet og problemstilling er svært avgrenset noe som gjør at vi vet at undersøkelsen krever målbare data. Disse målbare dataene, kommer vi til å få fram gjennom prototypetesting. Testresultatene blir avlest i form av tids-, kvalitets- og kostnadsvariasjoner, hvilke er høyst målbare data. Alt dette underbygger at vi skal benytte kvantitativ metode i dette prosjektet. Ved datainnsamling med den kvantitative metode er begrepene validitet og pålitelighet veldig viktige. Ved denne type studier er det viktig at rett type data er samlet inn på en pålitelig måte. Gjennomgående er det viktig med god observasjon og dokumentasjon, slik at andre skal forstå fremgangsmåten for å kunne utføre videre forskning med dette prosjektets dokumentasjon som grunnlag Kvalitetssikring av testing Konseptet kvalitetssikring betyr at man gjennom standardiserte objektive tester når en forutbestemt pålitelighetsstandard. Gjennom riktig dokumentasjon og beskrivelse av testene, skal det være mulig å gjenta fremgangsmåten av testene, som skal gi lignende testresultat. For å sikre kvaliteten på dette prosjektet, vil vi ta i bruk tre viktige begreper. Disse er kvalitetssikring, utvikling og informasjon: Kvalitetssikring: For å få bekreftet resultatene vi kommer frem til gjennom dette prosjektet, vil vi lage et testmiljø der vi vil gjennomføre ulike tester. Dette testmiljøet er vår prototype. 31

32 Testene skal utføres på en slik måte, at de gir mest mulig presise resultater. Testmetoden skal ikke være årsaken til variasjoner av resultatene. Utvikling: Gjennom testing av prototypen vil vi produsere kunnskap, slik at vi senere kan benytte denne kunnskapen til å besvare problemstillingen i prosjektet. Informasjon: Gjennomgående er det svært viktig å observere og dokumentere prosjektet, slik at andre kan anvende seg av dokumentasjonen for videreutvikling eller gjenskaping av et lignende prosjekt. Samtidig må vi ikke glemme hva vitenskapsfilosofen Paul Feyerabend mente om forskning og forskningsmetoder. Han uttrykte stolt det berømte uttrykket "Anything Goes". Med dette mener han at forskningen ikke skal være bundet av bestemte metoder eller prinsipper, men være fri der alt er tillatt. 3.3 Design For å sikre god kvalitet og fremgang i prosjektet er det viktig med en god prosjektdesign. Gjennom prosjektdesignet vil vi tydeliggjøre hvilke mål vi har satt i prosjektet, hvordan vi skal nå målene og se på hvor gjennomførbare du ulike målene er. Selve prosjektdesignet er skissert opp og skjematisert i vedlegg Prosjektdesignets hovedstruktur I hovedtrekk er prosjektet delt inn i 2 hoveddeler. Disse er designmål A: Prototype, og designmål B: Undersøkelser og tester. Disse hovedmålene er viktige milepæler for prosjektet, og representerer to viktige og avgjørende tilnærminger i forhold til problemstillingen i prosjektet. Designdel A: Prototype Denne delen av prosjektdesignet, handler om å utarbeide det verktøyet som er kritisk for prosjektets videre gjennomføring. Som nevnt i kapittel 1, ønsker vi å finne ut om vi vil kunne klare å utvikle en grafikkprosesseringsprototype, basert på åpen kildekode, som kan sendes ut på en nettsky. Designdel A består av tre mål, som i hovedsak omhandler prosjektets første del, nemlig å lage en 32

33 fungerende prototype for grafikkprosessering. Denne prototypen skal hete Ymer og skal kunne utføre grafikkprosessering både lokalt på server og på nettskyen Amazon EC2. Mål A.1 er det første målet i designdel A. Her er målet å få til en fungerende infrastruktur med noder som kommuniserer. Det vil vi gjøre ved å lage et nettverk på serveren av virtuelle maskiner som kommuniserer. Mål A.2 handler om å utføre en grafikkprosessering lokalt, dette gjør at det lokale virtuelle nettverket, blir en renderfarm. De tekniske utfordringene i forhold til å nå disse målene er å få de ulike programvarene til å kommunisere. Mål A.3 er det siste målet i denne delen av prosjektet. Her er målet å klare å sende renderfarmen ut på en sky, altså å utføre en grafikkprosesseringsoppgave på Amazon EC2. Designdel B: Undersøkelser og tester Denne delen av prosjektdesignet, omhandler som navnet på designdelen tilsier, undersøkelser og tester. Mål B.1 og mål B.2 er begge mål som handler om forberedelser til de undersøkelsene vi skal gjøre, utforme undersøkelsene og finne, eventuelt lage de verktøyene vi trenger for å utføre testene. Mål B.3 har fokus på gjennomføring av testene, mens mål B.4 setter fokus på vurdering av dataene. Resultatet av designdel B, mål B.1 til B.3 vil bli en testbok, der alle tester og resultater vil bli presentert. (Vedlegg 5) For å få mest mulig pålitelige resultater, vil vi planlegge testene nøye. Ved å utføre enkelte tester flere ganger, mener vi at vi kan oppnå tilstrekkelig kvalitetssikring i forhold til resultatene. Vi vil også se til at kvaliteten på testene blir opprettholdt ved at samme type tester blir utført på samme måte hver gang. Hver test skal dokumenteres nøye slik at de får en høy grad av reproduserbarhet Konseptuell modell av prototype For å kunne sette opp en renderfarm som kjører på sky, må man skaffe seg en del komponenter. Under følger en oversikt over hva som trengs av både maskin og programvare. Server (PC). Denne maskinen vil være vert for den lokale renderfarmen, i tillegg til at man vil kunne administrere alt herfra, også de skybaserte renderfarmene. Maskinen skal ikke behøve inneha avanserte og dyre komponenter. 33

34 Programvare for server/operativsystem. For å kunne installere nødvendig programvare for en renderfarm, må maskinvaren som skal brukes ha en plattform. Her er det veldig mye å velge i, og valget man faller på vil legge føringer for valg av programvaren man kan velge senere i installasjonen. Men man kan i teorien bruke det meste av programvare for operativsystemer, både Linux- og Windows distribusjoner. Programvare for virtualisering. For å kunne ha flere virtuelle maskiner på en og samme maskinvare, må man ha et program som gjør dette mulig. I praksis vil det si at man må velge en virtualiseringsplattform som innehar en hypervisor. Noen alternativer for dette er VMware, Xen og Virtuozzo. Delt lagring. For at nodene enkelt skal kunne dele på en større jobb og fordele filer seg i mellom, trenger man en felles mappe i filsystemet, derfor er en slik programvare nødvendig. Programmer som kan brukes til dette kan for eksempel være Samba og NFS. IP-adresse. For at slavenodene skal kunne finne mesteren og kommunisere med denne på skyen, må man ha en kjent IP, eventuelt et kjent vertsnavn. I teorien er det vel flere muligheter for å løse denne, men de enkleste alternativene mener vi må være å betale for en fast IP hos de leverandørene som tilbyr dette. Da vil man lease den samme IP-adressen hver gang man starter opp mesternoden. Dette vil være enkelt, men ikke kostnadsfritt. En billigere løsning er å registrere et vertsnavn for noden hos en tjeneste slik som DynDNS.com, da dette er gratis. Når man har registrert et vertsnavn hos DynDNS (eks renderfront.dyndns.org), så vil man kunne nå noden via dette navnet, selv om IP-adressen endres. Grafikkprosesseringsprogram. En renderfarm trenger programvare for grafikkprosessering på alle slavenoder for å kunne utføre en oppgave. Med en oppgave, så menes grafikkprosessering av frames, det vil si bilder, som til sammen utgjør animasjon. Programmer som kan brukes til dette, er for eksempel Maya, Blender og CAD. Administrasjonsprogram for virtuelle nettverk. For å forenkle jobben det er å bygge og administrere renderfarmer bør man ha et verktøy som gjør denne jobben enklere. Programmer som gjør dette i større og mindre grad er Clustermaker, MLN (Manage Large Networks), OSCAR(Open Source Cluster Application Resources) og Rocks. 34

35 Køhåndteringsprogram ( queue manager ). For å kunne fordele en oppgave på flere noder, må man ha et verktøy som holder orden på hva som skal gjøres, og hvilke oppgaver som er utført. I denne sammenheng vil det si fordeling av jpg-filer, som hver og en representerer et bilde som skal grafikkprosesseres, som en del av for eksempel en animasjon. For denne oppgaven trenger man en køhåndteringsprogram, og det blir i hovedsak denne som skiller mesternoden fra slavenodene. Grender og DrQueue er programmer som kan fylle denne oppgaven. Skyleverandør. For å kunne utføre en grafikkprosessering på sky, må man ha en lisens hos en skyleverandør. Her er det flere aktører på markedet. Eksempler på aktører som tilbyr skyløsninger er Windows Azure, Amazon EC2 og Google App Engine. Per i dag tilbyr disse leverandørene et forskjellig spekter av tjenester, og dermed er ikke alle like aktuelle for vår type prosjekt. For dette prosjektet vil vi velge Amazone EC2 som skyleverandør, da Amazone EC2 er den største aktøren på markedet, og har det bredeste tilbudet på markedet innenfor nettskytjenester. Script som kobler nodene sammen. For at nodene skal finne hverandre på sky må man lage to script som gjør dette mulig. Et for mesternode og et for slavenoden. Scriptet bør også ta seg av konfigurering av all programvare på nodene som krever en kjent IP, ettersom man ikke vet hva den faktiske IP-adressen til slavenodene er før etter oppstart. Figur 3.1Illustrasjon av konseptuell modell av prototype 35

36 3.3.3 Kjernespørsmål Problemstillingen i dette prosjektet går ut på at vi skal utvikle en grafikkprosesseringsprototype som skal sendes ut på en nettsky, for at vi deretter skal kunne utføre undersøkelser i forhold til løsningens ytelse, forutsigbarhet og kvalitet, i tillegg til at vi skal se på de kostnadsmessige aspektene ved løsningen. For å opprettholde fokus på problemstillingen og hvilke aspekter vi ønsker å belyse, har vi formulert noen spørmål vi ønsker å besvare. Kjernespørsmålene vil være retningsgivende for designdel B, utforming av tester, undersøkelser og analyser. Sp. 1 Sp. 2 Sp. 3 Sp. 4 Sp. 5 Sp. 6 Sp. 7 Sp. 8 Sp. 9 Sp. 10 Sp. 11 Sp. 12 Sp. 13 Sp. 14 Sp. 15 Sp. 16 Sp. 17 Sp. 18 Sp. 19 Fungerer prototypen hver gang, og er den stabil? Hvor lang tid tar det å grafikkprosessere en fil på Amazon EC2 med 2 og 4 slavenoder med prototypen? Er det døgnvariasjoner i forhold til grafikkprosesseringstiden? Er det ulik grafikkprosesseringstid på Amazon EC2 sone EU og sone US? Er byggetiden forutsigbar og stabil? Er det døgnvariasjoner på byggetiden, og er det forskjell på sone EU og sone US? Hvordan er skalerbarheten i forhold til grafikkprosesseringstiden og antall slavenoder? Beholder prototypen kvaliteten på oppgaven i forhold til skaleringen? Hvor lang tid tar det å laste ned en fil fra en node på en nettsky? Har køhåndteringsprogrammet og den delte lagringen en øvre grense i forhold til pakkehåndtering og trafikk? Er datatrafikken jevn i forhold til skaleringen? Er tiden det tar å starte et prosjekt til alle noder er oppe stabil? Hvor lang tid tar det å grafikkprosessere en fil lokalt med en slave? Hva er forholdet mellom antall noder og ytelsestap? Er prototypen økonomisk lønnsom? Når er prototypen eventuelt ikke lenger lønnsom? Er skaleringen av ytelsen i samsvar med økte kostnader? Hva er kostnadene av et liknende reelt system i forhold til skaleringen? Hva er de juridiske retningslinjene på bruk av grafikkprosessering på sky? 36

37 3.3.4 Testbok I testboken vil vi ta utgangspunkt i prosjektdesignet og de målene vi har satt opp som viktige milepæler i prosjektet. Ved utforming av testene og ved gjennomføring av testene vil vi i hovedsak ha fokus på den tekniske dimensjonen. Med utgangspunkt i spørsmålene vi har formulert i prosjektdesignet, vil vi utarbeide testene slik at vi på en best mulig måte kan besvare disse. Testene vil i hovedsak basere seg på testing av ytelse, forutsigbarhet og kvalitet. Dette vil vi gjøre ved å forta målinger av hastighet på ulike deler av prosessen i forhold til å utføre en grafikkprosessering på Amazon EC2. Vi vil undersøke om det finnes døgnvariasjoner og variasjoner i forhold til størrelser på filer som skal prosesseres, samt i forhold til størrelsen på renderfarmprosjektet. I tillegg vil vi undersøke om det er forskjell på Amazon EC2 sone US og sone EU, og se om det er døgnvariasjoner i forhold til bygge- og sendetid for renderfarmprosjekter. For å få en bedre oversikt vil vi utarbeide et skjema der vi vil fremheve følgende: Hva skal testes? Hvorfor skal dette testes? Hvordan skal det testes? Testboken vil få en hierarkisk oppbygning, bestående av hovedtester og undertester. Der undertestene vil fange opp de ulike variasjonene innenfor samme type test. Vi har kommet fram til følgende hovedtester: 1. Måle tiden og døgnvariasjon på en grafikkprosesseringsoppgave på EC2, sone US, instanstype c1.small 2. Måle tiden og døgnvariasjon på en grafikkprosesseringsoppgave på EC2, sone EU, instanstype c1.small 3. Måle tiden det tar å bygge, sende, starte og pinge et renderfarmprosjekt ut på en nettsky 4. Grafikkprosessering av en stor fil, med økt antall noder. Er det samsvar mellom økt antall noder og kraft brukt i forhold til tid? (proporsjonalt / uproporsjonalt?) 5. Måle nedlastningstid av iso-fil fra sky, til server over 24 timer. 6. Måling av pakke og bytestrøm under grafikkprosessering 7. Tid det tar å starte et prosjekt til alle Amazon har allokert minne til alle noder 8. Lokal grafikkprosessering med en slave 9. Kostnader (undersøkelser og vurderinger rundt kostnadsaspektet) 37

38 Tilnærmingen til kostnadsdimensjonen vil bli litt annerledes enn til den tekniske dimensjonen. Resultatene vi får i forhold til kostnadsdimensjonen, vil bli funn som baserer seg på diverse undersøkelser gjort gjennom informasjonshenting og egne vurderinger. Utformingen av testboken baserer seg på skjemaer slik som vist nedenfor i figur 3.2. Det blir et skjema for hver test, der det framkommer detaljer i forhold til hva som skal testes og presentasjon av resultatene. Dersom det vil bli behov for flere tester, vil vi gjennomføre tilleggstestinger. Disse resultatene vil bli presentert i en egen del på slutten av testboken. I eksempelet nedenfor er tid på dagen en variasjon i testen dette er vist ved at hvert klokkeslett er en egen deltest. Alle testene blir presentert i testboken i vedlegg 5. Dersom det blir behov for ytterligere testing, vil disse resultatene bli presentert i eget vedlegg for tilleggstester. Figur 3.2 Eksempel på hvordan en test er utformet i testboken 38

39 3.4 Vurdering av prosjektdesignet Prosjektdesignet er bygd opp på den måten vi mener er mest hensiktsmessig, og som passer best i forhold til problemstillingen i dette prosjektet. Sett i forhold til at et lignende prosjekt ikke har blitt gjort eller dokumentert tidligere, så mener vi det er riktig å tilnærme oss denne oppgaven på en klassisk undersøkende vitenskapelig måte. Ved først å lage en prototype som fungerer, for deretter å foreta tester mot denne, mener vi at vi vil kunne klare å påvise gode, presise resultater som kan gi oss et godt utgangspunkt for å vurdere løsningens ytelse, forutsigbarhet og kvalitet. En slik tilnærming til en problemstilling er en ganske vanlig metode for et prosjekt av denne typen. Kan vi velge en annen tilnærming til problemstillingen? Problemstillingen i dette prosjektet er av en slik karakter, at det gjør det vanskelig å se for seg en annen tilnærmingsmetode enn den vi har valgt. Man kunne ha valgt en metode der vi hadde satt større fokus på målgruppen: små og mellomstore bedrifter. Det kunne vært gjort gjennom mer direkte samarbeid med en bedrift av denne størrelsen. Ved å benytte en server i bedriften, utført grafikkprosessering av grafikkfiler relatert til bedriftens behov og utført tester i bedriftens eget miljø, ville man kunne få virkelighetsnære resultater for denne bedriften og deres spesifikke oppgaver. Vi mener at resultatene av en slik tilnærming ville være nyttige for enkelte bransjebedrifter, men at en slik tilnærming ikke ville gi oss den innsikten vi ville fram til gjennom prosjektet. Dette mener vi fordi vi da ikke ville fått den objektive tilnærmingen vi mener er viktig for en slik type oppgave. En annen tilnærming som kunne vært interessant, er om vi hadde valgt en mer teoretisk tilnærming. En slik tilnærming kunne innebefatte ulike spørreundersøkelser der vi kartla bedrifters behov for grafikkprosessering, kunnskapsnivå om hva nettskyer er og hva de tilbyr, samt hva ulike bedrifter ville være interessert i å betale for en nettskyløsning. Ved å kartlegge denne typen informasjon, ville man kunne danne seg et bilde av denne type prosjekts betydning og mulighet. Dette ville bli et godt utgangspunkt for fremtidig forskning. Selv om en slik tilnærming antageligvis ville være av stor interesse, ville dette kreve at vi hadde måttet endre problemstillingen i prosjektet, da resultatene av en slik tilnærming ikke ville være tilstrekkelig for å besvare vår problemstilling. 39

40 Kapittel 4 Resultat I dette kapittelet vil vi presentere Ymer, vår prototype. Med utgangspunkt i den konseptuelle modellen av prototypen beskrevet i kapittel 3.3.2, vil vi beskrive komponentene i Ymer. Deretter vil vi gi en teknisk beskrivelse av fremgangsmåte for Ymer, før vi tilslutt presenterer resultatene, både av de tekniske testene og av kostnadsundersøkelsene. 4.1 Implementering av Ymer Dette kapittelet beskriver valgte komponenter for Ymer, samt beskrivelse for hvordan vi gikk frem for å utvikle Ymer Ymer Server. Vi har valgt å bruke en enkel server som base for Ymer. Serveren har en enkelkjernet cpu og 2GB RAM. Dette valget ble gjort på grunnlag av problemstillingen vår, som blandt annet har miljøaspektet som et punkt. Man skal med andre ord ikke behøve en ny og kostbar server for å få vår prototype til å fungere. Operativsystem. Fordi vi vil lage en prototype som skal være billigst mulig å anskaffe, og tilgjengelig for alle, har programvare med åpen kildekode vært et enkelt valg for oss. Serverprogramvarekategorien er det mye å velge i, og vi valgte Debian Linux. Vi valgte dette 40

41 blandt annet fordi vi har noe kjennskap til Debian Linux fra tideligere. Debian Linux er også kompatibel med de andre komponentene vi har valgt, og har åpen kildekode. Dette er et krav for alle komponenter vi bruker. Xen programvare for virtualisering som innehar hypervisor. Vi valgte å bruke Xen Hypervisor som virtualiseringsplattform. Xen er veldokumentert, har åpen kildekode, og tilbyr også et forum for support. Vi har heller ingen grunn til å anta at dette er noe dårligere enn andre alternativer. NFS delt lagring. NFS er vel utprøvd og en velkjent programvare for nettverksfilsystemer. Vi har valgt og bruker NFS user server, da denne kun kjører i brukerområdet og ikke som kjerne. Dette gjør den litt tregere, samtidig som den ikke vil forårsake systemkrasj om noe feiler. Vi får ikke konfigurert tilgang til serveren før etter at prosjektet er på EC2-nettverket, dermed så er det viktig at serveren vi bruker er forholdsvis enkel å konfigurere. Vi har heller ikke kontroll over kjernen som brukes av Amazon EC2, så vi tar høyde for at NFS-kernel-server ikke er installert på den kjernen. NFS-user-server vil derfor alltid fungere. DynDNS, vertsnavn. I teorien er det flere muligheter for å løse problematikken det er å finne ut hva masternodens IP-adresse på sky-nettverket. Vi lekte med tanker som gikk ut på å gjøre en brute force, det vil si å prøve alle IP-adresser innen et område, men ettersom vår skyløsning er et privat A- nettverk, forkastet vi ideen fort fordi det ville ta for mye tid. Man kan også betale for en elastisk IP hos noen leverandører. Dette vil være enkelt, men også mer kostbart. Den billigste og kanskje enkleste løsningen er å registrere en IP hos DynDNS. DynDNS er gratis og har TTL på 60 sekunder (oppdateres hvert 60 sekund), hvilket gjør den både effektiv og pålitelig. Det er gratis å registrere IP-adresser med alias hos DynDNS, så derfor falt valget på dette. Fordi kostnad er et aspekt som er tungtveiende i prosjekt Ymer, prøvde vi å holde de nede så langt det lot seg gjøre. DynDNS har visst seg å være en pålitelig tjeneste som fungerer bra. Grafikkprosesseringsprogram. Valget av grafikkprosesseringsprogram falt på Blender. Kostnadsaspektet ble selvfølgelig et av argumentene her også. Blender er gratis og har åpenkildekode som alle andre komponenter vi bruker. Samtidig føler vi oss sikre på at Blender holder høy kvalitet, og innehar funksjonalitet på like høyt nivå som andre kostbare 41

42 grafikkprosesseringsverktøy. Administrasjonsprogram for virtuelle nettverk. For å bygge Ymer trengte vi et verktøy som kunne forenkle jobben med å bygge og administrere virtuelle maskiner. Vi valgte MLN fordi MLN har støtte for Xen, og blant annet har et plugin som sender klynger med virtuelle maskiner til Amazon EC2, samt et plugin som gjør det mulig å tilknytte mesternoden DynDNS, og dermed gjøre den mulig å spore i et privat nettverk. MLN er også godt dokumentert, noe som gjør den relativt brukervennlig for oss som ikke har så mye erfaring med klynger av virtuelle datamaskiner. Køhåndteringsprogram ( queue manager ). Vi har brukt DrQueue som køhåndteringsprogram. Vi har ingen grunn til å anta at DrQueue er noe dårligere enn andre tilsvarende programmer. Og ikke minst så er det gratis, tilgjengelig for alle, og innehar åpen kildekode. Skyleverandør. Vi valgte å benytte oss av Amazon EC2 som skyleverandør, fordi Amazon er den eneste aktøren som tilbyr en løsning som passer vårt prosjekt. Script som kobler nodene sammen. For at slavenodene skal kunne finne mesternoden på sky, laget vi to Perlscript som sørget for den nødvendige infrastrukturen. Et for mesternoden som fungerer som er den lyttende part, og et for slavenodene som kobler seg opp mot mesternoden. Scriptet inneholder i korte trekk to deler, en del for mesternoden, og en del for slavenodene. Etter at slavenoden har gjort et DNS-oppslag på vertsnavnet vi har registrert for mesternoden hos DynDNS, så sørger scriptene for at NFS konfigureres slik at man har mulighet til å dele ressurser mellom mester og slavenoden. Etter dette konfigureres DrQueue, og renderfarmen er etter dette klar til bruk. 42

43 Figur 4.1Illustrasjon av prototypen Ymer Teknisk beskrivelse og fremgangsmåte for Ymer Dette kapittelet vil kort forklare hvordan vi gikk frem for å lage vår prototype. Fordi vi har brukt flere renderfarmprosjekter i dette prosjektet, så vil renderfarmene kunne ha et navn for instanstype (eks: renderfarmprosjekt, instanstype c1.xlarge). Installasjon av serverprogramvare Innledningsvis fikk vi tildelt en server. Her installerte vi Debian Linux og konfigurerte internettilgang, for deretter å installere Xen. Xen er delt opp i tre deler. Dette er Domain 0, Domain U og hypervisoren. Vi administrerer alt fra Domain 0 gjennom SSH, så vi installerte derfor MLN i Domain 0. Klargjøring av filsystem for mester og slavenode Etter å ha installert programvaren vi trengte på serveren, bygget vi to imager, det vil si to filsystemer, et for mesternoden og et for slavenodene. I praksis betyr dette at man installerer all programvare rendernodene trenger i et filsystem, slik at det er klart til bruk. For å forenkle bygging av flere renderfarmprosjekter, kan man senere enkelt kopiere disse to filsystemene så mange ganger man ønsker. En ting man bør vite, er at når man sender et renderfarmprosjekt til nettskyen, så vil man aldri behøve sende mer enn to filsystemer, et for mesternoden og et for slavenodene. Dette betyr at et renderfarmprosjekt med 16 slavenoder ikke bruker noen lenger tid ut til nettskyen, enn et renderfarmprosjekt med 2 slavenoder. I EC2 omtales disse filsystemene som AMIs (Amazon Machine Image), og de registreres med et unikt identifikasjonsnummer. 43

44 I filsystemet for mesternoden installerte vi NFS-user-server. Vi installerte deretter DrQueue i mntmappen, som er mappen mesternoden senere vil dele med slavenodene. Tanken her var å forenkle installasjonen av DrQueue ved å legge den på NFS, slik at den blir delt med slavenoden når den kobler seg opp mot mesternoden. Dette gjør det derfor overflødig å forhåndsinstallere DrQueue i filsystemet for slavenodene. I filsystemet for slavenodene installerte vi NFS-klient og Blender, som er grafikkprosesseringsverktøyet som vi har valgt å bruke. Script Vi har skrevet to script i Perl, som man kan si fungerer som lim i oppsettet av Ymer. Dette var nødvendig fordi det ikke er mulig å ha en ferdigkonfigurert og fungerende renderfarm på Amazon EC2, helt fra oppstart. Scriptene er komplekse, blant annet fordi Amazon EC2 tildeler nodene nye interne og offentlige IP-adresser i det renderfarmprosjektet startes opp, og dermed vil nodene i praksis være blinde på dette tidspunktet. Dette betyr at de ikke vil kunne vite hva deres egen IP og nettmaske er, og ikke hva IP-adressen til de andre nodene i renderfarmprosjektet er. Renderfarmprosjektene kan ha forskjellige DynDNS-navn, og man bør derfor også kunne endre dette uten å endre i selve slavenodescriptet, ettersom det også vil kreve at man må gå inn i filsystemet til slavenoden. Dette ville vært en tungvindt og lite brukervennlig løsning. Dette problemet har vi løst ved at slavenodescriptet kjøres med mesternodens DynDNS-navn som argument ved oppstart på nettskyen. I praksis vil dette utgjøre en liten konfigurasjon i startup-blokken for slavenoden i MLNfilsystemmalen som gjelder for det aktuelle renderfarmprosjektet. Dette vil gjøre scriptene enkle å bruke. Figur 4.2 startup-blokken for slavenodene Fordi det ikke er mulig å forhåndskonfigurere det som er nødvendig for at NFS og DrQueue skal kunne fungere, sørger scriptene også for at mesternoden utveksler IP-adresse og nettmaske med slavenodene, slik at mesternoden kan konfigurere NFS og deretter restarte den. Først etter dette er det mulig for slavenodene å koble seg til mesternoden. DrQueue konfigureres i slavenodescriptet etter at den har koblet seg til, for så å starte opp DrQueue på alle noder. 44

45 Figur 4.3 Del av slavenodescript Figur 4.4 viser hvordan scriptene fungerer/ dialogen mellom mesternode og slavenode etter at renderfarmprosjektet er startet opp på nettskyen. Se vedlegg 4.1 for script. Figur 4.4 Script dialogen mellom mesternode og slavenode 45

46 MLN -filsystemmal Under følger et eksempel på en MLN-filsystemmal vi har brukt i prosjektet, hvor vi forklarer kort hva blokkene definerer, og hvordan små endringer kan forandre et renderfarmprosjekt. I global-blokken definerer man global informasjon for prosjektet. Her kan man også definere variabler og gi de verdier. Linje 2 definerer i eksempelet vårt, renderfarmprosjektets navn, og det er dette navnet man senere vil bruke når man stopper og starter et renderfarmprosjekt. Slavenodene som blir definert ved hjelp av autoenum-blokken, vil arve egenskaper fra superklassen rendernode. Figur 4.5 Autoenum-blokken I superclass common-blokken definerer man slavenodene. Her kommer også EC2-blokken inn. Det er denne som gjør det mulig å sende prosjektet på sky. På linje 18 definerer man hvilken type instans man vil ha på slavenodene. Vi har i hovedsak brukt m1.small og c1.xlarge. Dette vil i praksis, definere hvor mye kraft slavene vil få når de er i bruk på skyen. Man kan i denne blokken også definere hvilken sone man vil sende renderfarmprosjektet til. Her er sone US standard, så om man vil kjøre renderfarmprosjektet i en annen sone, så må dette defineres her, slik vi har gjort på linje 19 og

47 Figur 4.6 Superclass common-blokken Superclass rendernode arver fra superclass common, og her sørger startupblokken for at de siste konfigurasjonene for DrQueue blir gjort, samt oppstart av scriptet vi har laget for slavenoden. Figur 4.7 Superclass rendernode-blokken I host front-blokken defineres alt som har med system i front å gjøre, det vil si mesternoden. Denne blokken arver også fra superclass common. Vi vil at mesternoden skal starte opp litt før slavene fordi vi er avhengig av at DynDNS rekker oppdatere seg fort, slik at 47

48 slavenodene kan koble seg til mesternoden. Fordi MLN allerede har et plugin for DynDNS, har vi bare registrert oss med en DynDNS konto ( og opprettet et DynDNS navn (for eksempel renderfront.dyndnns.org), og lagt til DynDNS-blokken i MLN-filen. Kodeeksempel (nr) Figur 4.8 Host front-blokken Se vedlegg 4.2 MLN-fil, for fullstendig eksempel på MLN-fil. Når MLN-filen inneholder alt den skal, er den klar for bygging. Dette gjøres enkelt med kommandoen: render#: mln build - f 2SMALL.mln Denne kommandoen sørger i praksis for at man ikke bare bygger et prosjekt, men at det også sendes ut til skyen, så dette vil derfor ta noe tid. Hvis man er uheldig å glemmer noe, eller av en eller annen grunn skulle behøve å bygge prosjektet på nytt, så kan dette gjøres ved å overskrive på denne måten: render#: mln build - f 2SMALL.mln -r Når prosjektet først er bygd, kan man enkelt starte og stoppe det med kommandoene: render#~ : mln start -p 2SMALL render#~ : mln stop -p 2SMALL 48

49 Figur 4.9 Detalj fra AWS som viser antall noder på nettskyen Når renderfarmprosjektet er startet, kan man undersøke om instansene er på nettskyen ved for eksempel å logge inn på AWS-administrasjonskonsoll, med ditt brukernavn og passord hos Amazon EC2. 1. MLN administrerer renderfarmprosjektet 2. MLN bygger renderfarmprosjektet (sender det på nettskyen) 3. Renderfarmprosjektet oppdateres av DynDNS 4. Pålogging og kommunikasjon mot mesternode (grafikkprosesseringen administreres gjennom DrQman) 5. Administrasjon fra PC, gjennom SSH 49 Figur 4.10 Programvarediagram, Ymer

50 Etter å ha startet prosjektet på sky fra Dom 0, kan man logge på mesternoden med DynDNS adressen. DrQueue administreres med et grafisk grensesnitt (DrQman), og må man logge på med SSH: pc#~: ssh X root@renderfront.dyndns.org pc#~: drqman Etter at man har kjørt drqman-kommandoen skal det komme opp et brukergrensesnitt (se figur4.11). Derfra kan man se at alle slavenoder er tilkoblet mesternoden, og man starter enkelt opp en jobb. Figur 4.11 DrQman Se vedlegg 6 brukermanual for Ymer. 50

51 4.2 Resultat av tekniske tester Test 1: Måle tiden på en grafikkprosesseringsoppgave på EC2, sone US med times intervaller i en 24 timers periode, med prosjekter med 2 og 4 slavenoder med EC2 regionstype c1.small). Testene ble gjennomført ved at vi prosesserte en mindre fil (driven_hand.blend) på sky, med 60 bilder på to prosjekter, et med 2 slavenoder og et med 4 slavenoder. Vi dokumenterte resultater og funn ved å ta screenshots av detaljinformasjonen vi fant i brukergrensesnittet for DrQueue ved endt prosessering. Dataene vi var interessert i var tid brukt, bildetap og bekreftelse på at rett antall slavenoder var tilkoblet før oppstart av grafikkprosesseringsoppgave. Resultat: 2 slaver US 4 slaver US Gjennomsnitt: 00:06:48 00:06:48 Median: 00:06:38 00:06:38 Tabell 4.1 Sammenligning av grafikkprosesseringstid på 2 og 4 slavenoder - Sone US Tid 00:08:38 00:07:12 00:05:46 00:04:19 00:02:53 2 slavenoder 4 slavenoder 00:01:26 00:00:00 Tidspunkt Figur 4.12 Test 1 51

52 Test 2: Måle tiden på en grafikkprosesseringsoppgave på EC2, sone EU med times intervaller i en 12 timers periode, med prosjekter med 2 og 4 noder med EC2 instanstype c1.small. Testene ble gjennomført ved at vi prosesserte en mindre fil (driven_hand.blend) på sky, med 60 bilder på to prosjekter, et med 2 slavenoder og et med 4 slavenoder. Vi dokumenterte resultater og funn ved å ta skjermbilder av DrQman ved endt prosessering. Dataene vi var interessert i var tid brukt, bildetap og bekreftelse på at rett antall slavenoder var tilkoblet før oppstart av grafikkprosesseringsoppgave. Resultat: 2 slaver EU 4 slaver EU Gjennomsnitt: 00:06:32 00:03:23 Median: 00:06:25 00:03:21 Tabell 4.2 Sammenligning av grafikkprosesseringsitid på 2 og 4 slavenoder - Sone EU Tid 00:08:38 00:07:12 00:05:46 00:04:19 00:02:53 2 slavenoder 4 slavenoder 00:01:26 00:00:00 Tidspunkt Figur 4.13 Test 2 52

53 Test 3: Måle tiden det tar å bygge/sende, så starte og pinge et renderfarmprosjekt på sky. Testen ble utført ved å kjøre et script med intervaller. Scriptet vi brukte kan sees i vedlegg 3, kapittel 3.3. Test 3.1 Måle tiden det tar å bygge/sende, så starte og pinge et renderfarmprosjekt på sky, 24 timer. Resultat: Antall sekunder å bygge Antall sekunder å pinge Maksimumsverdi Minimumsverdi Gjennomsnittlig verdi: 1793,8 83,3 Median verdi: 1913,5 83,5 Tabell 4.3 Sekunder 2500 Summen av byggetid og "pingtid" (over 24 timer) Summen av byggetid og "pingtid" 0 Tidspunkt Figur 4.14 Test 3 Test 3.2 Måle tiden det tar å bygge/sende, så starte og pinge et renderfarmprosjekt på sky, 48 timer. Resultat: Antall sekunder å bygge Antall sekunder å pinge Maksimumsverdi Minimumsverdi Gjennomsnittlig verdi: 1637,9 77,1 Median verdi: Tabell

54 Persentil Sekunder 2500 Summen av byggetid og "pingetid" (over 48 timer) Summen av byggetid og "pingetid" Tidspunkt Test 3.3 Måle byggetid parallelt mot sone US og EU Figur 4.15 Test 3 Resultat: 47 % av verdiene er innenfor 25 % og 75 % Sekunder å bygge Sone USA Sekunder å bygge Sone EU % av verdiene er 914 innenfor % og % %: 1062, %: Median: Figur 4.16 Test 3 54

55 Figur 4.17 Test 3 Figur 4.18 Test 3 55

56 Test 4: Grafikkprosessering av stor fil, med 2, 4, 8 og 16 slavenoder, i sone US, instanstype c1.xlarge, og måling av bildetap. Testene ble gjennomført ved at vi prosesserte en større fil (driven_hand.blend) på sky, med 3000 bilder på fire forskjellige renderfarmprosjekter (2, 4, 8 og 16 slavenoder). Vi dokumenterte resultater og funn ved å ta screenshots av DrQman, ved endt prosessering. Dataene vi var interessert i var tid brukt, bildetap og bekreftelse på at rett antall slavenoder var tilkoblet før oppstart av grafikkprosesseringsoppgave. Resultat: Slavenoder Gjennomsnittstid i sekunder Tabell 4.5 Tid 00:17:17 Tiden det tar å grafikkprosessere en fil med 3000 bilder 00:14:24 00:11:31 00:08:38 00:05:46 2 slavenoder 4 slavenoder 8 slavenoder 16 slavenoder 00:02:53 00:00:00 Test 1 Test 2 Test 3 Test 4 Testomgang Figur 4.19 Test 4 56

57 Bildetap ved grafikkprosessering av fil med 3000 bilder Bildetap slavenoder 8 slavenoder 4 slavenoder Test 1 Test 2 Test 3 Test 4 2 slavenoder Figur 4.20 Test 4 Test 5: Måle nedlastningstid av en isofil fra node på sky, til server. Testen ble utført ved at vi kjørte et script som laster ned en fil fra en node i på sky, sone US. Scriptet tar tiden på nedlastingen, og skriver informasjonen til en fil. Filen vi lastet ned var på 2048MB. Vedlegg: Resultat: Gjennomsnitt: 3236 Maks: 3419 Min: 3133 Differanse: 286 Figur 4.21 Test 5 57

58 00:05 00:45 01:25 02:05 02:45 03:25 04:05 04:45 05:25 06:05 06:45 07:25 08:05 08:45 09:25 10:05 10:45 11:25 12:05 12:45 13:25 14:05 14:45 Sekunder Antall sekunder det tar å laste ned en ISO-fil :00 03:00 05:00 07:00 09:00 11:00 13:00 15:00 17:00 19:00 21:00 23:00 Tidspunkt Tidsbruk i sekunder Lineær (Tidsbruk i sekunder) Test 6: Måling av trafikkmengde under grafikkprosessering. Figur 4.22 Test 5 Testen ble utført ved at vi kjørte et script som registrerer all trafikk på portene til NFS og DrQueue og skriver informasjonen til en fil hvert 5 sekund, slik at vi kan se om det er en jevn/ujevn trafikk. Testen ble utført parallelt med test 4. Resultat: Resultatene viser at det er en jevn økning i pakke og bytestrøm i prosjekter med 2, 4 og 8 slavenoder. Det flater derimot ut med 16 slavenoder, samtidig som pakke og bytestrøm blir mer ujevn. Antall pakker DrQueue - Pakker - 2, 4, 8 og 16 slavenoder Tid Pakker INPUT (16xl) Pakker OUTPUT (16xl) Pakker INPUT (8xl) Pakker OUTPUT (8 xl) Pakker INPUT (4xl) Pakker OUTPUT (4xl) Pakker INPUT (2xl) Pakker OUTPUT (2xl) Figur 4.23 Test 6 58

59 00:05 00:45 01:25 02:05 02:45 03:25 04:05 04:45 05:25 06:05 06:45 07:25 08:05 08:45 09:25 10:05 10:45 11:25 12:05 12:45 13:25 14:05 14:45 00:05 00:45 01:25 02:05 02:45 03:25 04:05 04:45 05:25 06:05 06:45 07:25 08:05 08:45 09:25 10:05 10:45 11:25 12:05 12:45 13:25 14:05 14:45 Antall pakker NFS - Pakker - 2, 4, 8 og 16 slavenoder Pakker INPUT (16xl) Pakker OUTPUT (16xl) Pakker INPUT (8xl) Pakker OUTPUT (8xl) Pakker INPUT (4xl) 0 Tid Pakker OUTPUT (4xl) Figur 4.24 Test 6 Antall bytes DrQueue - Bytes - 2, 4, 8 og 16 slavenoder Tid Bytes INPUT (16xl) Bytes OUTPUT (16xl) Bytes INPUT (8xl) Bytes OUTPUT (8xl) Bytes INPUT (4xl) Bytes OUTPUT (4xl) Bytes INPUT (2xl) Bytes OUTPUT (2xl) Figur 4.25 Test 6 59

60 00:05 00:50 01:35 02:20 03:05 03:50 04:35 05:20 06:05 06:50 07:35 08:20 09:05 09:50 10:35 11:20 12:05 12:50 13:35 14:20 15:05 Antall bytes NFS - Bytes - 2, 4, 8 og 16 slaver Tid Bytes INPUT (16xl) Bytes OUTPUT (16xl) Bytes INPUT (8xl) Bytes OUTPUT (8xl) Bytes INPUT (4xl) Bytes OUTPUT (4xl) Bytes INPUT (2xl) Bytes OUTPUT (2xl) Figur 4.26 Test 6 60

61 Test 7: Tid det tar å starte et prosjekt lokalt til alle noder er oppe på Amazon EC2. Testene ble gjennomført ved at vi tok tiden fra oppstart av prosjekt, til alle noder stod oppført som oppe på Amazons EC2 kontrollpanel. Resultat: 2XL (3noder) 4XL (5noder) 8XL (9noder) 16XL (17noder) Gjennomsnittstid: 00:01:12 00:01:30 00:01:58 00:02:45 Tabell 4.7 Tid Tiden det tar fra MLN start til alle nodene er oppe, sammenligning av ulike renderfarmprosjekt med ulikt antall slavenoder 00:03:36 00:02:53 00:02:10 00:01:26 2XL (3 noder) 4XL (5 noder) 8XL (9 noder) 16XL (17 noder) 00:00:43 00:00:00 Test 1 Test 2 Test 3 Testrunder Figur 4.27 Test 7 61

62 Tid 00:03:36 Gjennomsnittstid før alle noder er oppe 00:02:53 00:02:10 00:01:26 Gjennomsnittstid 00:00:43 00:00:00 3 noder (2XL) 5 noder (4XL) 9 noder (8XL) 17 noder (16XL) Antall noder Figur 4.28 Test 7 Test 8: Test av lokal grafikkprosessering med stor fil og en slave. Testene ble gjennomført ved at vi prosesserte en større fil (driven_hand.blend) lokalt, med 3000 bilder på et prosjekt med en slavenode. Vi dokumenterte resultater og funn ved å ta skjermbilder av DrQman ved endt prosessering. Dataene vi var interessert i var tid brukt, bildetap og bekreftelse på at rett antall slavenoder var tilkoblet før oppstart av grafikkprosesseringsoppgave. Resultat: Fil Antall frames Enkel CPU Submission time Finish time Totaltid driven_hand.blend CPU 10:40:30 11:16:22 00:35:52 driven_hand.blend CPU 11:16:22 11:56:29 00:40:07 driven_hand.blend CPU 11:56:29 12:40:16 00:43:47 Gjennomsnittstid: 00:39:55 Tabell

63 4.3 Resultat av kostnadsundersøkelser Innkjøp av server tilsvarende EC2 For å kunne skape et godt vurderingsgrunnlag for hva tilsvarende maskinvare vil koste i forhold til EC2 instanser, har vi med utgangspunkt i den tekniske spesifikasjonen til EC2 instansen c1.xlarge, sett på prisene for tilsvarende maskinvare. Denne instanstypen består av følgende tekniske spesifikasjon: 7 GB mine 20 EC2 Dataenheter (8 virtuelle kjerner, E5410 klokkehastighet på 2.33GHz) 1690 GB lagrings plass Med den overnevnte instansen som utgangspunkt, gjorde vi et prisoverslag for hva et tilsvarende serveroppsett ville koste ved innkjøp. Alle prisene i dette denne kostnadsundersøkelsen, er innhentet fra et ledende selskap innen salg av maskinvare (se vedlegg nr 4). Tabell 4.9 viser hva innkjøpsprisen blir på reell maskinvare med datakraft tilsvarende den datakraften som renderfarmprosjekter med 2, 4, 6 og 16 slavenoder har: Antall slavenoder Innkjøpskostnad Tabell 4.9 Driftkostnader knyttet til innkjøp av server Kostnadene knyttet drift er delt inn i tre hovedkategorier. Disse er: Installasjon I de aller fleste tilfeller vil det være behov for at en systemadministrator setter opp systemet. Veiledende pris for en systemadministrator er estimert til Kr per time. Teknisk drift Systemet krever en deltidsansatt for teknisk vedlikehold. Veiledende pris for en slik ansatt vil ligge på kr per time. Et vanlig timeantall for en deltidsansatt er estimert til 75 timer per måned. Dette tilsvarer 900 timer per år. 63

64 Strømforbruk En renderfarm har et høyt strømforbruk. I prisoverslaget vi presenterer nedenfor, vil strømforbruket tilsvare 300W per rakkenhet. Vi har her estimert med en strømkostnad på 65 øre/kwh, og en oppetid på server som tilsvarer 8 timer per dag. Vi regner med 200W for kjøling av rakktårn, og at serveren har en oppetid på timer per år. Resultater knyttet til estimert teknisk drift Med utgangspunkt i spesifikasjonene gitt for installasjon, teknisk drift og strømforbruk, får vi følgende kostnadsestimat for teknisk drift: Installasjonskostnad, 24 timer, med installasjonstekniker, kr Teknisk drift, kr Strømkostnader årlig med en oppetid på 1800 timer. Tabell 4.10 viser hvilke strømkostnader renderfarmprosjekter av forskjellige størrelser ville hatt dersom disse representerte reell maskinvare: Antall noder Strøm forbruk i Forbruk i Kostnad kr/kwh Årlig basis Kostnad år W KW kr i KW/h kr 3 (2 Slavenoder) ,1 0, (4 Slavenoder) ,7 0, (8 Slavenoder) ,9 0, (16 Slavenoder) ,3 0, Tabell 4.10 Tabell 4.11 viser kostnadene relatert til drift og oppstart for det første året. I denne tabellen er det også tatt utgangspunkt i ulike renderfarmprosjekter, og hva kostnaden ville vært for maskinvare med tilsvarende størrelse: Antall slavenodernoder Innkjøp i kr Oppsett i kr Drift 50% i kr Strøm i kr Total kostnad kr Tabell

65 Kostnad for oppsett og bruk av Amazon EC2 Pris for bruk av instanser i EC2: Pris per time, per instans, altså per node, er kr 3,95 (0,68 USD x 5,8). Dette vil medføre følgende prisøkning ved økning av antall slavenoder: Antall slavenoder Pris/h NOK 2 11, , , ,05 Tabell 4.12 I prisene vist i tabell 4.12 er Mesternoden tatt med i beregningen. Dette innebærer at et prosjekt som har to slavenoder totalt operer med tre instanser. 65

66 Kapittel 5 Analyse og diskusjon 5.1 Analyse og diskusjon av testresultater Fungerer Ymer hver gang, og er den stabil? Resultatene av test 1 og 2 (Måle tiden på EC2 US og EU, fra start til stopp på en grafikkprosesseringsoppgave med 2 og 4 slavenoder), viser at Ymer fungerer godt og virker svært forutsigbar. Det var ingen tester som feilet på grunn av tekniske vanskeligheter, men fordi DrQueue opplyser om gjennomsnittstid brukt pr bilde, ville vi kontrollere tiden DrQman oppga som estimert brukt tid, ved å multiplisere tid brukt pr bilde med det totale antall bilder. Tiden vi kom frem til her var alltid noe høyere enn tiden DrQman oppga, noe som antageligvis henger sammen med at DrQman runder av sine tall, nedover mot kun to målepunkter per minutt. Disse testene krevde også grundig planlegging fordi de ble utført døgnet rundt av forskjellige personer. Fordi vi ville at testene skulle gjennomføres så likt som mulig, så det ble laget et dokument som beskriver hvordan man skulle teste, og hva som skulle hentes ut av informasjon. Gjennomføringen av testene gikk uten problemer. Hvor lang tid tar det å grafikkprosessere en fil på Amazon EC2 med 2 og 4 slavenoder? Grafikkprosesseringstiden renderfarmprosjektene brukte, varierte ikke mye. Dette tilsier at Amazon EC2 ikke har store variasjoner i hvor god ytelse de klarer levere. 66

67 Er det døgnvariasjoner i forhold til grafikkprosesseringstiden? Resultatene viser også at det er noe forskjell på hvor stabilt tidsbruk det er i de to sonene vi har testet mot. Sone EU har jevnt over et lavere tidsbruk pr grafikkprosessering, uavhengig av tidspunkt og størrelse på renderfarmprosjekt. Sone US har i tillegg større variasjoner i tidsbruk enn sone EU, dermed kan det tyde på at sone EU ikke bare leverer bedre ytelse, men også en mer stabil nettsky. Tid 00:08:38 00:07:12 00:05:46 00:04:19 00:02:53 00:01:26 Sammenligning av grafikkprosseseringstid, Sone EU og US 2 slavenoder, Sone US 2 slavenoder, Sone EU 4 slavenoder, Sone US 4 slavenoder, Sone EU 00:00:00 Tidspunkt Figur 5.1 Figur 5.1 viser at sone EU har en jevnere og bedre ytelse enn sone US. Er byggetiden forutsigbar og stabil? Test 3 (Måle tiden det tar å bygge, starte og pinge et prosjekt på sky) viser at byggetiden er forutsigbar i den forstand at Ymer ikke feiler. Tidsbruken har derimot variert en del, spesielt mot sone US. Her var det relativt stor variasjon, sammenlignet med sone EU som hadde et mye jevnere tidsbruk. Byggetiden mot sone EU var også her en god del kortere enn mot sone US, og sone US kom heller aldri ned i like lave byggetider som sone EU. Sone EU virker derfor mer forutsigbar enn sone US. Byggetid mot sone EU er 15 min i gjennomsnitt, mens bygging mot sone US bruker 19 min i gjennomsnitt. Vi kan si at byggetiden vil ligge på omkring 17 min i gjennomsnitt uavhengig av sone. 67

68 Figur 5.2 Figur 5.3 Hvordan er skalerbarheten i forhold til grafikkprosesseringstiden og antall slaver? Test 4 (Måle tiden på en stor grafikkprosesseringsoppgave med ulike antall slavenoder, sone US) viser at vi får bortimot 100 % redusert tidsbruk pr grafikkprosessering for hver gang vi fordobler antall slavenoder frem til renderfarmprosjekt med 8 slavenoder. Etter dette så ser vi en utflatning i ytelse, samtidig som bildetapet øker markant. Hva er forholdet mellom antall noder og ytelsestap? Slik Ymer fungerer nå, så kan det se ut til at man oppnår et optimalt forhold mellom ytelse og kvalitet ved brukt av renderfarm prosjekter med omkring 10 slavenoder (se figur 5.4). Etter dette vil det mest sannsynlig ikke være lønnsomt å øke antall noder noe mer. Man vil alltids kunne redusere tidsbruken noe med å ha for eksempel 16 slavenoder, men kvaliteten på animasjonen vil da ikke være like god, og man vil også få en større kostnad. 68

69 Grafikkprosesseringstid 00:17:17 Sammenheng mellom antall slavenoder, grafikkprosesseringstid og bildetap Antall bildetap 30 00:14: :11:31 00:08: Grafikkprosessering stid Bildetap 00:05: :02: :00: Antall slavenoder 0 Figur 5.4 Hvor lang tid tar det å laste ned en fil fra en node på sky? Test 5, (Måle nedlastningstid av en iso-fil fra node på nettsky, til server) viser at nedlastingstiden fra node på nettsky, til server, er veldig jevn. Det tok i gjennomsnitt 54 minutter å laste ned filen, og variasjonene var små, med en forskjell på 5 minutter mellom laveste og høyeste tid målt. Sekunder Antall sekunder det tar å laste ned en ISO-fil :00 03:00 05:00 07:00 09:00 11:00 13:00 15:00 17:00 19:00 21:00 23:00 Tidspunkt Tidsbruk i sekunder Lineær (Tidsbruk i sekunder) Figur

70 00:05 00:20 00:35 00:50 01:05 01:20 01:35 01:50 02:05 02:20 02:35 02:50 03:05 03:20 03:35 03:50 04:05 04:20 04:35 04:50 Har DrQueue og NFS en øvre grense i forhold til pakkehåndtering og trafikk? Test 6 (Måling av trafikkmengde) viser at det er en tydelig grense for hvor mye trafikk Ymer klarer å håndtere. Vi ser at det ikke gir noen stor gevinst å øke fra 8 til 16 slavenoder i et renderfarmprosjekt. Man sparer riktignok tid, men man får også en pakke og bytestrøm som er svært ujevn, noe som vi antar vil gi bildetap. Vi antar at DrQueue er hovedårsaken til at det ikke skalerer perfekt med renderfarmprosjekt med 16 slavenoder Var datatrafikken jevn i forhold til skaleringen? Som man ser i figur 5.6, så ligger verken bytes inn eller ut hos DrQueue, noe høyere med 16 slavenoder, sammenlignet med 8. Resultatene av målinger av byte og pakkestrøm viser omtrent det samme, både for NFS og DrQueue. Datatrafikken er derfor kun jevn i forhold til skaleringen, ved bruk av renderfarmprosjekter med 2, 4 og 8 slavenoder. Bytes DrQueue - Bytes - 8 og 16 slaver Tid Bytes INPUT (16xl) Bytes OUTPUT (16xl) Bytes INPUT (8xl) Bytes OUTPUT (8xl) Figur 5.6 Er tiden det tar å starte et prosjekt til alle noder er oppe stabil? Test 7 (Tid det tar å starte et prosjekt til alle noder er oppe), viser at det er en jevn økning i tidsbruk jo flere slavenoder renderfarmprosjektet innehar. 70

71 Tid 00:03:36 Gjennomsnittstid før alle noder er oppe 00:02:53 00:02:10 00:01:26 Gjennomsnittstid 00:00:43 00:00:00 3 noder (2XL) 5 noder (4XL) 9 noder (8XL) 17 noder (16XL) Antall noder Figur 5.7 Hvor lang tid tar det å grafikkprosessere en fil lokalt med en slave? Resultat av test 8 (Måle tiden det tar å grafikkprosessere en stor fil lokalt med en slave) viser at det ikke virker å være noen store variasjoner i grafikkprosessering med en slave lokalt. Dette var ikke et overraskende resultat, og vi valgte derfor ikke å teste mer enn 3 ganger. Gjennomsnittstid brukt var 39 min 55 sekunder, og det var ikke noe bildetap. Diskusjon Ymer har på mange måter overrasket oss positivt. Testresultatene viser at vi har laget en prototype som fungerer godt, og som er svært forutsigbar. Ymer har likevel et forbedringspotensial. Hvor mange slavenoder er optimalt? Vi sier i analysekapittelet at den optimale kurven for ytelse flater ut ved bruk av flere enn ca 10 slavenoder, og dette ville vi derfor undersøke litt nærmere. Vi gjorde derfor noen tester med renderfarmprosjekt med 10 slavenoder av instanstype c1.xlarge (samme instanstype som er brukt i test 4), og fikk våre antagelser bekreftet. Som man ser i figur 5.9, så vil man få økt ytelse om man øker fra 8 til 10 slavenoder. Bildetapet blir høyere, men det er ingen eksplosiv økning, slik vi så det 71

72 ble med 16 slavenoder. Man vil få økt ytelse med 16 slavenoder også, men fordi bildetapet og kostnadene blir så høye, vil vi ikke si dette er en god løsning. Antall bildetap 120 Totalt antall bildetap Bildetap Antall slavenoder Figur 5.8 Grafikkprossesseringstid der 10 slavenoder er inkludert Tid 00:17:17 00:14:24 00:11:31 00:08:38 00:05:46 2 slavenoder 4 slavenoder 8 slavenoder 10 slavenoder 16 slavenoder 00:02:53 00:00:00 Test 1 Test 2 Test 3 Test 4 Testrunder Figur 5.9 Vi vil se litt nærmere på skaleringen som testresultatene av test 4 viser. Egentlig så burde jo 4 slavenoder grafikkprosessere dobbelt så fort som 2, 8 slavenoder burde gjort samme jobb dobbelt så fort som 4 osv. Vi hadde ikke en 100 % reduksjon i tid for hver gang vi doblet antall slavenoder, men 72

73 vi er likevel nokså fornøyd med resultatene. Figur 5.10 viser vår kurve, sammenlignet med hvordan kurven burde sett ut om alt fungerte perfekt. Ytelse 18 Tap av ytelse Ytelses økning Optimal ytelses øking Antall slavenoder Figur 5.10 Ser man på de faktiske tallene, så ser vi også at vi er ganske nærme 100 % ytelsesøkning, men at det avviker mer og mer fra den optimale økningen, jo flere slavenoder vi bruker. Sammenligning av Ymers tid med optimal tid Slavenoder Gjennomsnittstid i sekunder Slavenoder Optimal tid i sekunder ,5 Tabell 5.1 Ytelse på bekostning av bildekvalitet? Nå kan man diskutere om et resultat med bildetap er bra nok kvalitet, sett i et mer virkelighetsnært perspektiv. Vil dette være bra nok for en bedrift, for eksempel? Ved grafikkprosessering av animasjoner ønsker man optimalt sett ikke noe bildetap, da dette blant annet kan forårsake forskyvninger i tidslinjen, og gjøre animasjonen usynkronisert. Så om Ymer skulle blitt tatt i bruk i 73

74 dag, og det ble forventet at den ikke skulle miste noen bilder, så ville det optimale antall slavenoder være ca 4-6, fordi vi kan anta at vi da vil klare grafikkprosessere uten bildetap. Dette er noe skuffende, samtidig så må vi se det positive i at vi har klart å lage en prototype som faktisk fungerer, og som alltid kommer opp på nettskyen, klar til å ta i mot en grafikkprosesseringsoppgave. Disse begrensningene vi mener å se, må sees i sammenheng med at det er noe med Ymer som gjør at vi ikke klarer utnytte oss av all kraft nettskyen har å tilby. Vi har ingen grunn til å anta at det er Amazon EC2 som forårsaker denne flaskehalsen, og velger derfor heller å se nærmere på prototypen vår. Ymers begrensninger Det har vært noen problemer med å få kjørt renderfarmprosjekt med 16 slavenoder (instanstype c1.xlarge), grunnet køhåndteringsprogrammet, som har virket overbelastet. Brukergrensesnittet har tidvis hengt, tidvis sluttet virke, og det har også tidvis visst tall som ikke gir noen mening. Vi har tidligere sagt at Ymer ikke feiler, men dette blir relativt ettersom vi jo har funnet begrensninger med prototypen, og dermed kan konkludere med at den ikke fungerer like godt under alle forhold. Fordi DrQueue virket forvirret så måtte vi under testene av 16slaversprosjektene kontrollere at tallene som DrQueue viser var riktige. Derfor ble tiden tatt med stoppeklokke i tillegg. Vi kunne ved avlesning av brukergrensesnittet derfor ikke regne ut tidsbruk ut i fra gjennomsnittstid pr bilde, men gikk ut i fra differansen mellom «submission time» og «estimated finishtime», som så ut til å stemme. Tallene i disse testene er derfor basert på en litt annen målemetode, men vi mener likevel at kvaliteten på resultatene er gode nok, og kan anses som valide. Vi antar derfor at DrQueue har noen begrensninger i forhold til hvor mange slavenoder den klarer å håndtere, og må også da ta høyde for at våre tester utført med 16slaverprosjektet, ikke viser resultater som er 100 % pålitelige. Det at prosjekt med 16 slavenoder ikke ser ut til å fungere 100 % under praktisk bruk av brukergrensesnitt, underbygger våre antagelser om at vi må se nærmere på køhåndteringsprogrammet om vi ønsker en renderfarm som yter bedre, samtidig som den ikke taper bilder. Vi har grunn til å tro at man ved å bytte ut DrQueue, kan få et renderfarmprosjekt som fungerer enda bedre. Vi vet ikke hvilken programvare som eventuelt kunne vært aktuell, men vi antar at det finnes mer eller mindre avanserte køhåndteringsprogrammer tilgjengelig. Man kunne eventuelt vurdere å gjøre endringer i DrQueue selv, for eksempel i form av å sørge for at den prosesserer tapte bilder på nytt, da dette vil forhindre at det blir tidsforskyvninger i resultatet. Kvaliteten vil fortsatt bli noe dårligere, men animasjonen vil ikke bli usynkronisert. Nå har ikke vi fokus på å optimalisere DrQueue i dette prosjektet, så dette er et spørsmål må vi la stå åpent. 74

75 Man kan spørre seg om det er flere faktorer i vår prototype som gjør at vi ikke klarer utnytte oss bedre av ressursene Amazon EC2 tilbyr. NFS-varianten vi bruker er ikke av den hurtigste, og vi vet heller ikke om det er den beste løsningen ettersom vi ikke har forsøkt noe annet. Man kunne også undersøkt om det finnes alternativer her som ville kunne få opp farten slavene bruker på å skrive resultatet til disk, eventuelt om det hadde vært mulig å bruke NFS kernelversjonen, som visstnok skal være hurtigere. Byggetid Byggetiden et prosjekt bruker, er i praksis det samme som tiden det tar fra å sende prosjektet fra lokal server til Amazon EC2. Denne testen viser derfor variasjoner i nettbelasting i ruten mot destinasjonssonen, som var både US (USA) og EU (England). Her testet vi med et renderfarmprosjekt av type c1.small med 2 slavenoder mot både sone US, og sone EU. Resultatene fra disse testene viste at man mot sone US opplevde ganske store døgnvariasjoner. I sone EU ser man at det ikke er like store variasjoner, og byggetiden er jevnt over lavere enn i US. Dette mener vi kan komme av at Amazons nettsky i Europa ligger lokalisert nærmere oss, og at det derfor vil innebære en kortere reiserute for pakkene som representerer et renderfarmprosjekt. Sone US kom aldri ned i like lave byggetider som EU, og dette underbygger våre antagelser. Hvilken sone bør man benytte seg av? Som kapittelet for kostnadsanalyser opplyser om, så er det noe rimeligere prismessig, å bruke nettskyen til Amazon i sone US. Dermed så er det argumenter som taler for både sone US og sone EU. Ønsker man forutsigbarhet i forhold til byggetid, og generelt lavere tidsbruk så er EU det beste alternativet, men er kostnader et viktigere aspekt, så er US et bedre valg. Et tredje aspekt er det juridiske, ettersom lovverket for det landet nettskyen befinner seg i er det som gjelder. Dette aspektet diskuteres i kapittel 5.4. Man må huske på at det ikke tar noe lenger tid å bygge et prosjekt med 2 slavenoder enn med 16 slavenoder, så med mindre det er viktig å spare de minuttene som vi antar at differansen i byggetid vil utgjøre på det meste, så kan man spare en del kostnader ved å benytte seg av sone US. Vi har testet døgnvariasjoner med grafikkprosessering på nettsky og mener vi har et godt grunnlag for å kunne anta at det ikke er nevneverdige døgnvariasjoner i ytelsen man får av Amazon EC2 i noen av sonene vi har testet mot. Ytelsesforbedringen fra renderfarmprosjekt med 2 slavenoder til 75

76 renderfarmprosjekt med 4 slavenoder, er tilnærmet 100 % i begge soner. Likevel ligger sone EU litt foran sone US her også, uten at vi vet noe om årsaken til dette. Lokal renderfarm eller skybasert? For å skape et godt sammenligningsgrunnlag for ytelse, kvalitet og forutsigbarhet av renderfarmprosjekter kjørt lokalt sammenlignet med prosjekter kjørt på nettsky, så ville vi utføre noen få tester lokalt på vår server. Serveren har en enkeltkjernet CPU, og vi valgte derfor å gjøre disse testene med kun en slave. Testen som ble gjort med renderfarmprosjekt med 2 slavenoder (instanstype c1.xlarge), tok i gjennomsnitt 15 minutter og 15 sekunder, mens den lokale testen med tilsvarende antall bilder, tok 39 minutter og 55 sekunder. Vi syntes ikke resultatene for de lokale testene viste så høyt tidsbruk som vi hadde forventet. Man bør derfor være oppmerksom på at det ikke er noe i veien for å bruke Ymer til grafikkprosessering lokalt. Har man en bedre server, og ikke fokus på tidsbruk, så kan dette fungere svært bra for mindre oppgaver. Andre betraktninger Vi testet tiden det tar fra man bygger et renderfarmprosjekt, starter det, deretter kan nå mesternoden med «ping». For at slavenodene skal kunne finne mesternoden må den kunne nås ved DNS-oppslag som gjøres via slavenodens script, noe som avhenger av at MLNs DynDNS-plugin og DynDNS fungerer som det skal. Her fikk vi også resultater som er noe påvirket av allokeringstiden Amazon EC2 bruker for å gi minne til nodene (derfor ble det besluttet at dette skulle bli en egen test i tillegg). Disse testene viste noen variasjoner, uten at vi kan forklare disse noe ytterligere. Det gledelige var at testen aldri feilet denne gangen heller. Ymer startet opp hver eneste gang. Tiden det tar fra man starter opp et prosjekt lokalt, til det er oppe på nettsky og klar til bruk, målte vi med stoppeklokke. Resultatene viser at det går radig å allokere minne til 2, 4 og 6 slavenoders prosjektene. Med mester vil disse prosjektene ha henholdsvis 3, 5 og 9 noder. A Men når vi startet prosjektet med 16 slavenoder, det vil si 17 noder med mester, så virket det som at Amazon måtte allokere minne i to omganger. De første 10 nodene kom helt opp før de siste 7 visste seg på panelet. Dette forklarer hvorfor renderfarmprosjekt med 16 slavenoder, brukte en del lenger tid på å komme opp. Vi antok først at det var DrQueue som hadde problemer, eller at det var mesternodescriptet vårt som laget en flaskehals, men det ser altså ut til å være Amazon EC2. 76

77 Vi ville også forsikre oss om at nedlastingstiden fra nettskyen sone US ikke viste noen vesentlige variasjoner, og valgte derfor å teste dette ved å laste ned en større fil med jevne intervaller over 24 timers periode. Her var resultatene utelukkende bekreftende, i forhold til våre antagelser. Noen variasjoner var det selvsagt, men dette er ikke noe som vil være utslagsgivende i stor grad når det kommer til den totale tidsbruken. Dette er riktignok ikke en problemstilling man har ved lokal grafikkprosessering, og dermed en bakdel man må veie opp mot fordelene om man velger å grafikkprosessere på nettsky. 5.3 Analyse av kostnadsdimensjonen Et av de viktigste argumentene for om en bedrift skal benytte seg av en skybasert tjeneste framfor å kjøpe inn tilsvarende maskinvare, er spørsmål knyttet til kostnad. I dette kapittelet har vi forsøkt å belyse kostnadsaspektet ved å se på Amazon EC2-tjenestens priser, samt innhentet priser for maskinvare tilsvarende ytelsen EC2 leverer. Vi har deretter sammenlignet og drøftet funnene. Vi vil begynne med å presentere hva en server tilsvarende instansen c1.xlarge koster. En instanstype c1.xlarge tilsvarer følgene rakkenhet: To firekjerners prosessor med klokkehastighet på 2,40GHz, 8GB minne og en lagrings plass på hele 1500GB. Vi valgte å sammenligne med instanstype c1.xlarge, fordi vi i test 4, benyttet denne instanstypen. Ettersom EC2-tjenesten gjør det mulig å ha renderfarmprosjekter med forskjellig antall slavenoder, vil vi presentere 6 ulike serverløsninger, hvor prisen tilsvarer antall instanser brukt hos Amazon EC2. Ser man på serverens innkjøpskostnad i forhold til hvor mange arbeidstimer dette tilsvarer for Ymer, kommer vi fram til følgende resultat som vist i tabellen nedenfor: Antall slavenoder Innkjøpskostnad Pris/h NOK Antall timer , , , , , , Tabell

78 Kolonnen Antall timer i tabell 5.2 viser innkjøpskostnaden på tilsvarende maskinvare delt på timeprisen hos EC2. Dette gir oss antall kjørbare timer på EC2 som tilsvarer innkjøpskostnaden av en renderfarm med størrelse angitt i kolonnen Antall slavenoder. Dette betyr at innkjøpskostnaden for en maskinvare tilsvarende 2 slavenoder på EC2 ( NOK), gir arbeidstimer på skyen. Dette blir ca 1850 arbeidsdager hvor EC2 skyen jobber 8 timer om dagen. I stedet for å kjøpe inn tilsvarende maskinvare, kan man la Ymer arbeide i 8 timer om dagen i mer enn 5 år på EC2, for samme kostnad. Grafen vist i figur 5.11 viser forholdet mellom innkjøpskostnader kontra brukstid av Amazon EC2. Kostnad i NOK XL Noder kr/h XL Noder kr/h 6 XL Noder kr/h 8 XL Noder kr/h 10 XL Noder kr/h 16 XL Noder kr/h Innkjøp 2 XL Noder Innkjøp 4 XL Noder Innkjøp 6 XL Noder Innkjøp 8 XL Noder Innkjøp 10 XL Noder Innkjøp 16 XL Noder Antall Timer Figur 5.11 Utfordringen ved å forsøke å sammenligne en Amazon EC2-instans mot en server med tilsvarende kraft, er at en server har flere tilleggskostnader. En server krever blant annet vedlikehold, oppbevaring, og strøm til både kjøling og kjøring. Vi vil tydeliggjøre de ulike kostnadene med to eksempler. Eksempel 1 viser kostnader knyttet til innkjøp av server og første driftsår. Eksempel 2 78

79 viser kostnadene sett i forhold til ytelsen man får ved å benytte seg av nettskyen med renderfarmprosjekter med forskjellig antall slavenoder. Eksempel 1: Driftkostnad for server Serveren i dette eksempelet vil ha et ytelsesnivå likt et renderfarmprosjekt med 8 slavenoder. Det vil derfor ha 72 prosessorkjerner, 63GB minne og 15210GB lagringsplass. I dette eksempelet tenker vi oss at bedriften har en egen oppbevaringsplass for selve serveren. Vi vil fokusere på følgende punkter: Innkjøpskostnaden Installasjon og montering Strømkostnad Årlig driftskostnad Innkjøpskostnad: Etter vår prisestimering ligger prisanslaget for en server som tilsvarer renderfarmprosjekt med 8 slavenoder, inklusivt moms og frakt, på kr (se vedlegg nr5). Installasjon og montering: Vi anslår at en systemadministrator vil bruke ca 3 arbeidsdager (24 timer) på å sette opp systemet. Systemadministratorens timepris vil ligge på ca. kr i timen. Dette tilsvarer en engangskostnad på kr Strøm: En server har et høyt strømforbruk. Alle komponenter i en server er strømkrevende. I tillegg genererer systemet varme, og må derfor kjøles ned. I vår utregning vist i tabell 5.3, kommer vi fram til at en server tilsvarende renderfarmprosjekt med 8 slavenoder som har en oppetid på 1800 timer, vil årlig ha en strømkostnad på kr Strøm forbruk i Forbruk i Årlig basis Kostnad Kr/KWh Kostnad år W KW 1800 h kr kr , , Årlige driftskostnader: Tabell 5.3 Vi kan anta at en virksomhet vil utnytte serveren sin flittig. Serveren vil ha en oppetid som tilsvarer 79

80 en heltidsansatt. Dette skaper behov for ulike systemoppdateringer, samt diverse servicetilfeller. Vi antar at det kreves en deltidsansatt for å vedlikeholde systemet. Den driftansvarliges lønn vil ligge på ca. kr i timen. Personen vil årlig jobbe ca 900 timer med en kostnad på kr i året. Er Ymer økonomisk lønnsom eller ikke? Etter våre beregninger vil en server med innkjøpspris på ca. kr , samlet koste kr 1,45 millioner det første året. De følgende årene trengs bare løpende driftskostnader, som i dette eksempelet utgjør ca. 1 million kroner. Merk deg at en server etter fire år vil bli ansett som utdatert. Hvis serveren utfører oppgaver som krever minimal oppdatering og vedlikehold, minsker denne kostnaden. Dette gjør det vanskelig og estimere den eksakte driftkostnaden, da de økonomiske variablene blir for mange. Dette problematiserer muligheten for å sammenligne kostnadene med en EC2-tjeneste. Derimot kan vi med den overstående analyse med sikkerhet påpeke at Ymer vil være økonomisk lønnsom for et mindre foretak. Eksempel 2: Kostnad knyttet til antall slavenoder og ytelse I eksempel 2 ønsker vi å fokusere på nytteeffekten EC2-tjenesten gir med dens mulighet til og enhver tid gi ønsket mengde kraft. Ved å regne ut hva kostnadene for grafikkprosessering blir i forhold til bruk av renderfarmprosjekter med tilsvarende antall slavenoder, kommer vi fram til følgene resultat: Ferdig film i tid 1min 40 sek 1min 40 sek 100 timer 100 timer Antall bilder I nok I timer I nok I timer 2 slavenoder 3,011 0, slavenoder 2,569 0, slavenoder 2,454 0, slavenoder 2,613 0, slavenoder 3,520 0, Tabell 5.4 viser antall bilder som skal prosesseres, hvor lang tid dette tar og kostnaden av selve utregningen. Grunnlag for disse tallene baserer seg på resultatene av test 4 og tilleggstester. Ved prosessering av bilder vil totalkostnadene bli veldig små. For å tydeliggjøre kostnadene øker vi verdiene i tabellen fra sekunder til timer (som tilsvarer en økning på 3600 ganger). Tabell 5.4 Tabell 5.4 viser at 100 timer ferdig grafikkprosessert animasjon vil ta 916 timer for et renderfarmprosjekt med 2 slavernoder. Dette vil koste kr Derimot vil 100 timer ferdig animasjon ta 469 timer og koste kr med 4 slavenoder. Ved å øke antall slavenoder til 4, vil Ymer bruke mindre tid og vi vil samtidig få en kostnadsminsking på hele kr

81 Om man ser på renderfarmprosjektet med 6 slavenoder, ser vi at både arbeidstiden og kostnaden minsker. Arbeidstiden minker til 320 timer og kostnaden synker til kr Igjen ser vi at ved å øke antall slavenoder, så sparer vi mer tid og penger. I forhold til et renderfarmprosjekt med 4 slavenoder sparer vi nå kr 414 og arbeidstiden er minsket med 149 timer. Dersom vi sammenligner arbeidstid og pris på renderfarmprosjekt med 2 og 6 slavenoder, vil vi med 6 slavenoder spare kr og minske arbeidstiden med 596 timer. Her ser vi den klare økonomiske fordelen ved å skalere. Hvis vi fortsetter å øke antall slavenoder til 8 slavenoder, ser vi nå at vi fortsatt får en forminsking av arbeidstid, mens prisen øker. For å minske arbeidstiden med 55 timer, vil det koste kr 571. Pris per minsket arbeidstime blir kr 10,30. For og tydeligere vise utflatingen ser vi på forholdet mellom renderfarmprosjekt med 8 og 16 slavenoder. Igjen ser vi at arbeidstiden minskes med 76 timer, mens prisen derimot øker med kr Dette gir oss en pris per minsket arbeidstime på kr 42,97 hvilket er fire ganger mer enn fra 6 til 8 slavenoder. Dette vises tydelig i figur Er skaleringen av ytelsen i samsvar med økte kostnader? Som vist i figur 5.12 kan skaleringen i forhold til arbeidstid sees på som en god investering opptil 6 slavenoder, hvor kostnaden og arbeidstiden fortsatt minsker. Dersom pris er det viktigste aspektet, kan vi gjennom figuren se at Ymer vil ha sin optimale økonomiske styrke ved 6 slavenoder. Figur 5.12 viser at dersom tidsaspektet er det viktigste, vil det fortsatt finnes tid og spare ved å øke antall slavenoder fra 8 til 16 slavenoder. Derimot med et så høyt antall slavenoder (8 til 16), taper bedriften den økonomiske fordelen. Tiden spart får nå en mye høyere kostnad. Vi kan med dette konstatere at ytelsen ikke er i samsvar med kostnaden, når et renderfarmprosjekt har over 6 slavenoder. 81

82 Sammenheng mellom arbeidstid og pris Tid Antall Timer Pris i NOK Pris Figur 5.12 Årsaken til det overnevnte er at renderfarmoppsettet trenger en masternode, som er en node som ikke utfører prosesseringsarbeid, men som likevel koster penger. Prosentuelt fører dette til at i et oppsett med to slavenoder er det 66.6 % av den samlede innleide kraften som utfører selve grafikkprosesseringen. I forskjell til et oppsett med 8 slavenoder hvor 88.8 % av den samlede innleide kraften utfører grafikkprosesseringen. Takket være dette prosjektets dokumentasjon, så blir kostnaden for å lage en prototype tilsvarende Ymer, grovt redusert. Vi regner med at en teknisk kompetent systemadministrator, med de riktige verktøyene (MLN) og dokumentasjon, vil bruke 5 arbeids dager på å lage en kopi av prosjekt Ymer. Dette tidsestimatet kan virke i underkant i forhold til den faktiske tiden som ble brukt til utvikling av Ymer, men vi mener likevel at det vil ta mye kortere tid og utvikle en nettskybasert renderfarm nå som det foreligger en eksisterende løsning med teknisk dokumentasjon, i form av Ymer. 5.4 De juridiske aspektene Dersom man skal undersøke hvorvidt en grafikkprosesseringsløsning på nettsky vil egne seg for små og mellomstore bedrifter, er det viktig å sette seg inn i hvilke lovverk som gjelder for skybasert teknologi. Den teknologiske utviklingen innen nettsky-tjenester har hatt en enorm framdrift de siste 82

83 årene. Våre undersøkelser i forhold til den juridiske dimensjonen ved skybasert teknologi, kan tyde på at denne teknologien ligger foran lovgivningen. Det eksisterende lovverket vedrørende bruk av nettskytjenester bærer preg av å være veldig mangelfullt, og vi mener derfor at retningslinjene ikke er gode nok når det gjelder lagring av data på en nettsky. Et av de største utfordringene som oppstår i forhold til lovgivning og retningslinjer for bruk av nettsky-tjenester, er behovet for gode lover som ikke står i strid med nasjonale lover. I dag ser vi at ved å følge lovverket i et land, kan man bryte lovverket i et annet. Dette er et stort problem for tjenester som skybaserte løsninger tilbyr. Generelt kan vi si at leverandørene av nettskyene er pålagt å følge lovverket som eksisterer i det landet nettskyene er lokalisert. Leverandøren har det overordnede juridiske ansvaret for nettskyen, og sitter dermed med de juridiske problemene i forhold til å tilby en tjeneste som ikke går på tvers av de ulike retningslinjene som eksisterer samtidig som de skal overholde de lover de er pålagt i vertslandet. Kunden på sin side må forholde seg til de lover som gjelder for den nettskyen kunden ønsker å benytte, altså det landet der nettskyen er lokalisert. I tillegg er mange bedrifter underlagt nasjonale lover og forskrifter i forhold til datalagring, så som personvernloven og bokføringsloven som vi har i Norge. Nettskyteknologien bringer derfor med seg utfordringer i forhold til sikkerhet og plassering av data. Etter hvert som bruk av nettsky-tjenester blir mer vanlig, vil det haste å komme fram til gode globale retningslinjer, men dette er en vanskelig og omfattende prosess. Som en del av våre undersøkelser i forhold til de juridiske aspektene, tok vi kontakt med datatilsynet i Norge. Vi ble oversaket over å finne ut at det per i dag ikke eksisterer noen konkrete retningslinjer for bruk av nettsky-tjenester. De forsikret oss om at dette var en høyt prioritert sak og at datatilsynet var i ferd med å utarbeide retningslinjer for dette. Samtidig kunne de opplyse om at norske myndigheter på sin side stilte seg avventende i forhold til denne problemstillingen, og ønsket å vente til teknologien var mer utbredt og utprøvd før de foretok seg noe. Dette skyldes nok at enkelte andre land er kommet lengre i forhold til å ta i bruk denne teknologien og at det i dag ikke eksisterer noen norsk skyleverandør med en nettsky lokalisert i Norge. Vi vil anta at lovgivningsprosessen ville få en fortgang, dersom flere bedrifter hadde ytret ønsker om å gjøre bruk av de tjenestene nettskyer tilbyr. Databransjen ønsker fortgang i denne prosessen, slik at de lettere kan løfte fram skybaserte systemer som en reell løsning for bedrifter i dag. Ved å få et mer konkret og overordnet globalt lovverk, håper 83

84 databransjen at dette kan gjøre skybaserte systemer mer attraktivt for bedrifter som vegrer seg å bruke disse løsningene på grunn av de juridiske komplikasjonene. 5.6 Evaluering av prosjektet Å gjennomføre et prosjekt av denne typen, i forhold til prosjektets kompleksitet og teknisk høye nivå, kan ha sine utfordringer. Disse utfordringene sett i forhold til tidsbegrensningene og at de skal løses sammen gjennom gruppearbeid, kan gjøre prosjekter av denne typen vanskelige å gjennomføre på en god måte Prosjektets kompleksitet Vi ville gjennom denne oppgaven utvikle en åpen kildekodebasert grafikkprosesseringsprototype som kunne benyttes ut på en nettsky, slik at vi kunne forta undersøkelser i forhold til ytelse, forutsigbarhet og kvalitet, samt foreta undersøker i forhold til kostnadsdimensjonen. For å imøtekomme denne problemstillingen ville det kreve at vi måtte: Lage en prototype for grafikkprosessering på Amazon EC2 Utføre nødvendige undersøkelser og tester Analysere testresultatene og se de i sammenheng med problemstillingen Undersøkelser gjort i forprosjektet og planleggingsfasen av prosjektet viste at det ikke fantes noen dokumentasjon på at det tidligere hadde vært utført lignende undersøkelser der de samme komponentene og verktøyene var tatt i bruk. Som et utgangspunkt for prosjektet, hadde vi derfor følgende punkter: Gruppens forkunnskaper vedrørende temaet og de programvarene vi skulle benytte i prosjektet, var minimale Gruppens tekniske kunnskap vedrørende brukt teknologi var lav, og måtte tilegne oss den tekniske kunnskapen underveis i prosjektet Usikkerhet om en prototype i praksis var mulig å bygge, siden det ikke forelå noen dokumentasjon på dette 84

85 Prototypen ville bestå av mange tekniske komponenter (6 komponenter), som er med på å øke den tekniske vanskelighetsgraden ved gjennomføringen av oppgaven Vi visste ikke om vi ville klare å bygge prototypen, og om vi i det hele tatt ville kunne klare å utføre de undersøkelsene vi hadde satt som mål å undersøke Dette utgangspunktet, sett i sammenheng med manglende sammenlignbare data, mener vi er sentrale i forhold til definering av prosjektets kompleksitet Faglige utfordringer For å kunne bygge en skybasert grafikkprosesseringsprototype, kreves det kunnskaper på et høyt teknisk nivå. Vår erfaring er at dette er et komplekst tema som det tar tid både å forstå og lære seg. Gruppens faglige forkunnskaper begrenset seg til noe bruk av Linux, samt noe script og programmeringserfaring fra et par relevante kurs vi har hatt i regi av høyskolen. Vi hadde ikke kunnskaper om hvordan grafikk prosesseres, hvordan en renderfarm fungerer eller inngående kunnskaper om hva en skyleverandør kunne tilby. Selv om vi har hatt noe scripting og programmering i tidligere kurs, viste det seg at vårt begrensede tekniske nivå ble en av de største utfordringene i prosjektet, fordi dette prosjektet var veldig teknisk komplisert med mange og ukjente komponenter. Innledningsvis krevde oppgaven en god del scripting, for at vi skulle kunne få en klynge av datamaskiner koblet opp mot hverandre. Dette hadde ingen i gruppen gjort før, og det tok en god del tid å lære seg hvordan et socketscript skulle skrives i perl. I tillegg tok det også mye tid få på plass de andre nødvendige delene for at prototypen skulle fungere. Vi hadde i tiden før prosjektstart, brukt noe tid på å lære perl bedre, noe som vi tror bidro til at vi kom raskt i gang og gjorde oppgavene noe mer overkommelig, selv om det helt klart var utfordrende. Installering av maskinvare, og lære seg å bruke disse, viste seg å bli ganske komplisert. Ingen av gruppemedlemmene hadde erfaring med installasjon av programvare som skulle fungere på flere klienter, der klientene hadde forskjellige roller i forhold til hverandre. Dette opplevdes som forvirrende, spesielt ved installering av køhåndteringssystemet DrQueue. Vi opplevde at dokumentasjonen vi fant, ikke var detaljert nok og at den var tidvis mangelfull, sett fra nybegynneres perspektiv. 85

86 Parallelt med utfordringene vi hadde i forhold til utviklingen av prototypen, begynte vi utformingen av prosjektdesignet, prosjektrapporten og testene. Det ble ganske mye antagelser på dette tidspunktet, fordi vi ikke helt klarte å se konturene av prosjektet i sin helhet. Vi brukt noe tid på å få fullstendig oversikt over helheten på en slik måte at vi kunne få god nok innsikt til å kunne utforme gode mål og tester som ville bli nyttige for prosjektet. Etter at vi hadde fått alle programmene til å fungere og testet alt lokalt, var vi klare for å sende det hele ut på sky. Dette gikk veldig greit, blant annet fordi MLN har et plugin som gjør mye for oss. Ting gikk fra dette tidspunktet mer knirkefritt sammenlignet med tideligere, selv om det stadig dukket opp feilmeldinger av forskjellige slag, fordi vi hadde en del «barnesykdommer» i filsystemet vi brukte på de virtuelle maskinene. Dette ble derfor etter hvert byttet ut. Det skal også nevnes at en del selvforskyldte feil oppstod på grunn av oversette detaljer, forvirring og menneskelig svikt. Dette ga oss noen forsinkelser, men også mange oppdagelser og nyttige erfaringer underveis. Etter å ha gjennomført prosjektet, kan vi konkludere med at det største aspektet ved de tekniske utfordringene har vært at det har krevd mye å tilegne seg så store mengder kunnskap og forståelse på såpass kort tid. Det har også vært krevende å holde orden på detaljene og komponentene som har vært mange og komplekse. Det har vært nok av problemstillinger som har fortonet seg som abstrakte, fordi de har vært vanskelig å se for seg før man får testet det ut i praksis. Dette har også bidratt til at rapportskriving også har vært krevende, spesielt i planleggingsfasen. 5.7 Evaluering av gruppeorganisering Vi som har jobbet sammen i dette prosjektet, er fire studenter som ved flere anledninger tidligere har samarbeidet ved ulike prosjekt i studiet Anvendt Datateknologi ved Høgskolen i Oslo. For å sikre et godt og produktivt samarbeid i hovedprosjektet, utarbeidet vi i fellesskap noen retningslinjer og regler for prosjektsamarbeid. Filosofi og mål Et overordnet hovedmål med prosjektet, var å lære mest mulig. Både i forhold til de tekniske utfordringene og i forhold til de faglige aspektene vedrørende selve prosjektgjennomføringen. Gjennom godt samarbeid, god kommunikasjon, grundig planlegging og synliggjøring av risikoer, ville vi gjennomføre et suksessfullt hovedprosjekt som hele gruppen ville kunne stå inne for og være fornøyd med. 86

87 Arbeidsmetoder Oppgavene i prosjektet ble fordelt innad i gruppen, slik at gruppemedlemmene hadde hver sine ansvarsområder. Dette mente vi var hensiktsmessig for prosjektets fremdrift og kvalitet. Selv om et gruppemedlem ble gitt et spesielt ansvar for en oppgave, har arbeidet blitt gjennomført ofte i samarbeid mellom enkelte eller alle i gruppen. Arbeidsformen i gruppen kunne variere avhengig av oppgavenes form og art. Gruppeorganisering I løpet av tiden vi har jobbet med dette prosjektet, har hver enkelt i gruppen vært involvert i ulike deler av prosjektoppgavene, men i hovedsak kan vi si at gruppen ble organisert på følgende måte: Linda Granstad (gruppeleder) Teknisk ansvarlig Hovedansvar for prototype Testing og analyser Patrik Nylén Ansvarlig for kostnadsdimensjon Research Testing Magnus B. Sheehan Ansvarlig for juridisk vurdering Research Testing og analyser Liv Karin Sameien Hovedansvar for prosjektrapport Testboken Systematisering og presentasjon av testdata Samarbeid Da vi i gruppen hadde ulike timeplaner i uken, både i forhold til annet skolearbeid, arbeid, familiære forhold osv. var det vanskelig å komme fram til en ukeplan der vi kunne sitte sammen å jobbe hver dag. Vi hadde i utgangspunktet et ønske om, så langt det lot seg gjøre, å forsøke å imøtekomme hver enkelt gruppemedlems behov og ønsker i forhold til arbeidsrutiner. En slik fleksibilitet i gruppearbeidet kan være utfordrende, og god kommunikasjon og planlegging er en forutsetning for at en slik løsning skal være vellykket. Vi hadde ukentlige møter og kjernetidspunkt for når hele 87

88 gruppen skulle være på skolen, men opplevde likevel enkelte utfordringer i forhold til å få nok tid sammen som gruppe. Beslutninger og tvister Vi opplevde få faglige uenigheter i prosjektet. På forhånd var vi enige om at avgjørelser skulle bli tatt gjennom diskusjon og avstemning. Det var felles enighet om at flertallets mening i gruppen skulle være gjeldende. Ved uenigheter ble veileder trukket inn i diskusjon og avstemning. 5.8 Resultatenes betydning I dette kapittelet vil vi se nærmere på hvor Ymer befinner seg i dag, bruksområder, fordeler og bakdeler, samt hvilke ringvirkninger Ymer og tilsvarende programvare vil kunne gi på sikt. Hvem passer Ymer for? Prototypen Ymer fungerer i dag svært stabilt, men har noe å gå på når det kommer til ytelse, kvalitet og brukervennlighet. Vi mener likevel at Ymer har sitt bruksområde, slik den fremstår i dag. Bedrifter med oppgaver som krever grafikkprosessering, krever tilgang til mye datakraft. For en slik bedrift kan det ofte være vanskelig å kombinere dette kravet med ønsker om lave driftskostnader. Spesielt blir dette vanskelig for mindre bedrifter. I dag vil Ymer kunne brukes av små og mellomstore bedrifter som har behov for grafikkprosessering i en mindre skala, for eksempel til instruksjonsfilmer og lignende. Dette vil bety at bedrifter som ikke vil drifte sin egen serverpark for dette formålet, kan bruke Ymer etter eget behov. Dette vil kunne spare de for høye kostnader relatert til kjøp av maskinvare, programvare, strøm og andre driftsutgifter. Derfor kan vi også anta at en skybasert tjeneste vil kunne være attraktiv for små og mellomstore bedrifter, og da kanskje spesielt de med mindre ressurser enn det de større aktørene i markedet har. Dette vil kunne gi de konkurransefordeler, fordi de vil løpe en lavere økonomisk risiko og dermed står sterkere. Ymer er i dag en prototype som har mange muligheter, men den har likevel en del å gå på når det kommer til brukervennlighet. Vi mener likevel å kunne påstå at Ymer i bruk, ikke tilsvarer vanskelighetsgraden det er å drifte sin egen serverpark. Man kan med noen grep også bruke den til mer enn grafikkprosessering, fordi en klynge av virtuelle maskiner kan brukes til mange forskjellige oppgaver. Dette betyr at Ymer har potensial til å kunne brukes i langt flere sammenhenger enn hva 88

89 den egentlig er tiltenkt, og at nedslagsfeltet for Ymer derfor kan være større enn hva man kanskje tror. Hva betyr Ymer, sett i en større sammenheng? Vi tror at Ymer er en liten brikke på veien mot det vi mener er fremtidens IT-løsninger. Man ser at det stadig blir større fokus på miljøvern og vi tror at dette er noe som kommer til å bli mer og mer populært. Desentralisert bruk av programvare, og innleid datakraft vil kunne gi oss et mindre forbruk på verdensbasis, fordi det blant annet gir maskinvare en lenger levetid og dermed forminsker utslipp av skadelig avfall. Det finnes flere eksempler hvorpå man har gått litt tilbake på funksjonalitet, fordi mange er villige til å gå på kompromiss med funksjonalitet for å skape seg en bedre miljøprofil. Her er EL-bilen et godt eksempel. Flere og flere er villig til å kjøpe denne bilen som ikke er egnet for all type kjøring, og som har sine klare begrensninger, fordi det gir de bedre samvittighet. Som en ekstra bonus vil også eierne få fordeler av å kunne benytte seg av gratis parkering, kollektive kjørefelt osv. Man kan se for seg at dette også vil kunne skje om man tilbød løsninger som Ymer, som riktignok kanskje har en vei og gå for å nå opp i toppskiktet ytelsesmessig, men som likevel gir deg det du trenger. Som en bonus kan man få bedre samvittighet, og kanskje også man på sikt vil kunne lage belønningsordninger, slik at miljøbesparende drift gir større fordeler enn hva det gjør i dag. Grønne IT-tjenester som fokuserer på miljøvern har også et velferdsaspekt, ettersom mindre behov for ny maskinvare og billigere inngangssummer til den teknologiske verden vil kunne gi svakere menneskegrupper større muligheter. Tilgang til internett, er det samme som å ha tilgang til informasjon og nye muligheter. Utdannelse og informasjon er en kjent nøkkel mot forkjemping av fattigdom. Hvem vil ikke bidra til å jevne ut menneskers levevilkår verden over? Ymers nedslagsfelt er kanskje ikke så stort sett med dagens øyne, men Roma ble heller ikke bygd på en dag. Vi har lykkes i å få en renderfarm til å fungere på en nettsky, og det med svært lave inngangskostnader. Ymer og alle dens programvarekomponenter vil ligge tilgjengelig på internett, slik at det blir mulig for andre å bygge sin egen skybaserte renderfarm, eller kanskje bare hente inspirasjon til egne prosjekter. Dette er et bidrag i fellesskapets ånd, slik programvare med åpen kildekode er ment å være. Vi håper at andre vil ta opp tråden og tenke muligheter videre med Ymer. 89

90 Kapittel 6 Konklusjon For å besvare problemstillingen i dette prosjektet, har vi utviklet Ymer, vår prototype. Med utgangspunkt i denne har vi utført en rekke undersøkelser og tester. Gjennom å analysere resultatene og se på betydningen av disse, mener vi at vi har klart å tilnærme oss og besvare problemstillingen på en god måte. 6.1 Oppsummering og konklusjon Den vanskelige begynnelsen Innledningsvis i dette prosjektet så vi kun konturene av det som skulle bli Ymer. Vi visste ikke om vi ville få prototypen til å virke, og om den i det hele tatt virket, så ante vi ikke i hvilken grad. De faglige utfordringene for oss som gruppe, har vært mange og store. Vi tok på oss et prosjekt som var teknisk svært komplisert, og som i tillegg var nytenkende og innovativt. Dette gjorde at vi måtte utforske mye selv, ettersom det ikke var mye dokumentasjon å finne for lignende prosjekter. Vi brukte en del vel utprøvde og kjente programvarekomponenter, men vi hadde ikke noen erfaring med dem selv fra før av, så det var ikke enkelt av den grunn, og vi slet med å få alt til å virke som vi ville. Vi utformet innledningsvis også et utkast til en testbok på grunnlag av ganske vage antagelser, ettersom vi da ikke helt forstod prosjektets kompleksitet. Det var enormt mye å lære på kort tid, men til slutt var Ymer et faktum. Vi satte etter dette i gang med å designe testene på et høyere detaljnivå ettersom innsikten vår nå var langt bedre, og vi så ting mer klart for oss. Etter dette ble testene utført uten at vi møtte på store vansker. 90

91 Testene og resultatene Resultatene av testene ga oss en positiv overraskelse i den forstand at Ymer fungerte svært bra i form av stabilitet og forutsigbarhet. Ettersom vi selv hadde scriptet limet som sørget for at Ymer startet opp som en renderfarm, var det svært gledelig å se at vår egen programvare ikke feilet. Testene som ble utført med renderfarmprosjekter hvor nodene var av størrelse c1.xlarge viste også at Ymer hadde begrensninger ettersom ytelsen ikke skalerte jevnt under testene som ble utført. Vi prøvde derfor på grunnlag av testresultatene, å finne ut hvordan man kunne klare å utnytte ressursene til Amazon EC2 mer effektivt, ved å prøve oss frem med forskjellige antall slavenoder. Resultatene av disse eksperimentene viste at ytelseskruven for alvor begynte flate ut ved bruk av flere enn 10 slavenoder, av instanstype c1.xlarge. Vi så en utflatning før dette også, men den var jevn frem til dette tidspunktet. Om man bruker flere enn 10 slavenoder øker også bildetapet mye, og dette gir resultatet redusert kvalitet. Om man forventer en fordobling i ytelse for hver gang man fordobler antall slavenoder, og ikke tolererer noe bildetap, så vil man ikke kunne ha mer enn 4-6 slavenoder i et Ymer renderfarmprosjekt med instanstype c1.xlarge. Her mener vi det er mye å hente ved å se nøyere på hva som forårsaker ytelsestapet. Vi antar at det er DrQueue som er hovedårsaken til at vi ikke klarer få en bedre skalering med 16 slavenoder, ettersom vi så at DrQueue tydelig hadde vansker med å håndtere 16 slavenoder. Brukergrensesnittet hang og viste verdier som ikke stemte, og det var vanskelig å administrere renderfarmprosjektet. Resultatene av testene som målte bytestrøm og pakkeflyt, bekreftet våre antagelser i stor grad, men om årsaken til utflatningen ligger her alene, eller om den ligger i maskinvarens begrensninger eller andre steder, det vet vi ikke. Testresultatene viste også at det er en forskjell på sonene Amazon EC2 opererer med. Vi gjorde grundige undersøkelser ved å sende ut prosjekter med jevne tidsintervaller mot begge soner, over flere døgn. Vi testet også om Amazon EC2 ga oss lik ytelse til en hver tid av døgnet. Her ser vi at det er EU som skiller seg ut som det beste alternativet. Byggetiden var mye jevnere, og selv den laveste verdien sone US viste, var aldri så lav som den høyeste verdien til sone EU. Sone US viser også noe lenger tidsbruk per grafikkprosesseringsoppgave, så vi kan derfor konkludere med at sone EU gir lavest og mest stabil byggetid, samt best ytelse på nettskyen. Kostnadsaspektet Kostnadsundersøkelsene vi gjorde, forteller oss at det likevel ikke bare er fordeler ved å bruke Amazon EC2, sone EU. Prisene man opererer med i Europa er generelt høyere, og dette er et viktig aspekt når man velger sone for grafikkprosessering med Ymer. Konklusjonen her er at sone US er 91

92 vinneren om man skal se på pris alene. Mindre og mellomstore bedrifter som ønsker å bruke en løsning som Ymer for grafikkprosessering, bør derfor vurdere flere aspekter når man velger sone. Et av hovedargumentene for å bruke Ymer, er at det vil kunne gi en bedrift mulighet til å utføre krevende grafikkprosesseringsoppgaver, uten å måtte ut med store investeringssummer i maskinvare. Dette vil gi små og mellomstore bedrifter mindre økonomisk risiko ved å starte opp selv, og dermed også større konkurransedyktighet i oppstartsfasen. Kostnadsanalysen forteller oss at man med Ymer kan grafikkprosessere på nettsky i ca timer før det blir lønnsomt å kjøpe inn egen maskinvare, forutsett at man ikke bruker over 16 slavenoder av størrelse c1.xlarge. Man må også huske på at det å ha en serverpark medfører ekstra kostnader som strøm, samt man må ha kompetanse til å drifte dette selv. Miljøaspektet En hver maskinvare har begrenset levetid. Dette betyr at dersom maskinvaren ikke brukes effektivt, vil dette være uhensiktsmessig dyrt å handle inn, samtidig som det gir oss alle et større miljøproblem om man hele tiden skal måtte kaste 5 år gammel maskinvare, fordi det er utdatert. Ved å bruke en nettskyløsning, så får man topp ytelse levert av en leverandør som har det beste og siste innen maskinvare. Man vil også slippe driftkostnader og strømkostnader, og som en bonus kunne drive bedriften sin med en mer miljøvennlig profil, noe som i dagens samfunn blir stadig viktigere. De juridiske aspektene Vi har sett at ytelse og pris har variert i de forskjellige sonene, men også lovverket som gjelder i det landet nettskyen er lokalisert, ser ut til å variere en del. Fordi nettskyer er et såpass nytt fenomen, er det lite vedtatte lover som gjelder problematikk direkte rettet mot akkurat dette. Dette tilsier at man bør sette seg godt inn gjeldene lovverk, før man bruker en nettsky til oppgaver som krever høy sikkerhet. Forbedringspotensialer Vi har i dette prosjektet utviklet en prototype som fungerer bra, men som har forbedringspotensial når det kommer til å øke ytelse, uten at kvaliteten reduseres. Vi ser også for oss at et brukergrensesnitt som gjør det mulig å bygge og administrere renderfarmprosjekter, vil gjøre Ymer til et mer aktuelt alternativ for bedrifter i dag, ettersom dette vil gjøre Ymer enklere i bruk. Man kunne ved en senere anledning også vurdert å involvere en bedrift ved videre utvikling, og dermed få en mer brukerrettet tilnærming. 92

93 Det gjenstår å se om utviklingen av IT-bransjen vil gå i samme retning som den til nå har gjort, med stadig ny og bedre maskinvare, og med en brukergruppe som har et stadig behov for å skaffe seg det nyeste og siste. Kanskje man etter hvert får opp øynene og begynner å tenke litt mer på hva det koster oss miljømessig å forbruke så mye, og retter fokus mot mulighetene som kan redusere problemet? Vi følger spent med på videreutvikling av programvare for nettskyer. 6.2 Fremtidig arbeid Det er alltid ting i et prosjekt man kunne vurdert å gjøre annerledes, ting man kan tenke seg å videreutvikle, og ikke minst ting man drømmer om at vil skje i fremtiden. Nettskyløsninger er en relativt ny måte og tenke på, og noen spår den et kort liv, mens andre har større tro. I dette kapittelet vil vi skissere noen emner vi mener burde tas nærmere i øyesyn, i fremtiden. Ymer Vi mener vår prototype har mange fremtidsmuligheter når det kommer til videreutvikling. Sånn den fremstår i dag, så kreves det en del IT-kompetanse å sette den opp, og noe IT-kompetanse å bruke den. Man kunne derfor vurdert å lage et skall som syr sammen de forskjellige komponentene, slik at brukeren vil oppleve Ymer som en sømløs og brukervennlig programvare. Dette kunne gjort den nåværende prototypen mer attraktiv, og dermed også mer aktuell for små bedrifter hvor man for eksempel ikke har en egen IT-ansvarlig eller råd til kostnadene det er å investere i dyr og kraftig maskinvare. Et annet spørsmål er om det er mulig å forbedre prototypen slik at man det blir mulig å utnytte Amazon EC2s ressurser i større grad. Vi antar at køhåndteringsprogrammet vi har brukt er noe av årsaken til at vi ikke er helt der i dag. Dette betyr at det i teorien burde være mulig å lage et køhåndteringsprogram som gjør at man klarer håndtere mer CPU-kraft, og flere slavenode. Dette vil kunne gjøre bruksområdet til Ymer en del større, men kanskje den også kan brukes til andre oppgaver? Ymer har sider ved seg som i dag fremstår som uferdig, men det vi har bevist, er at infrastrukturen fungerer veldig bra. Vi hadde en svært høy suksessrate når vi startet opp renderfarmprosjektene våre både på nettskyen, og lokalt. Det var heller selve oppgaven som skulle utføres, altså grafikkprosesseringen, som hadde sine begrensninger. En klynge av maskiner på en nettsky kan i praksis brukes til det meste av matematiske utregninger, og større og tyngre jobber. Dette åpner for at Ymer kan videreutvikles til å utføre andre typer arbeid. Kanskje det finnes andre typer oppgaver 93

94 som yter Ymer mer rettferd, slik den er i dag? Vi har ikke undersøkt om det i dag finnes en plass i arbeidslivet for Ymer, der den allerede nå kunne vært en fullverdig programvare, fordi vi ikke visste om den i det hele tatt ville kunne fungere. Man kunne derfor også vurdert å arbeide tett med en eller flere bedrifter, og utviklet Ymer videre med en tilnærming som var mer en klassisk systemutviklingsmetode, det vil si, med praktisk bruk og testing av system, etter definerte krav. Nettskyens utfordringer og muligheter Vi mener å kunne antyde at det i dag er lovverk som gjør at enkelte i dag er skeptiske til bruk av nettskyløsninger. Man risikerer å bli overrasket av lovverk som gjelder i landet nettskyen er lokalisert, og dermed er det ikke så ukomplisert å bruke nettskyløsninger likevel. Man kunne derfor vurdert og utforske bruk av nettskyløsninger bedre, for å se om bruken innebærer større risikoer. Risikerer man lekkasje av data, problemer med opphavsrettigheter, eller er det andre risikoer vi ikke vet om? Man kan også tenke seg at nettskyen vil kunne få en større brukergruppe om de var flere, slik at man kunne brukt en som var lokalisert i eget bostedsland. På den måten ville kanskje ikke lovverket komplisert bruken i like stor grad, noe som igjen kunne ført til at nettskyer ble en mer populær tjeneste på sikt. En større brukermasse vil dessuten som oftest bety at man får et tydeligere lovverk, og dette tror vi kan bidra til økt interesse for løsninger som Ymer. Fremtiden I dag finnes det bilkollektiv som reklamerer med å være fleksible, økonomiske og miljøvennlige. Her benytter opptil 10 familier seg av samme bil, slik at man får en mindre inngangskostnad til det å skaffe seg bil, i tillegg til at man står igjen med nedbrytning av 1 bil når den er utslitt, og ikke 10. Det burde vel være mulig trekke paralleller fra bilkollektiv, til IT-bransjen? Vi tror at deling av IT-ressurser er noe som vil bli mer og mer utbredt i fremtiden, fordi det blant annet vil kunne spare verden for nedbryting av skadelig avfall, som en direkte konsekvens av mindre forbruk av maskinvare. Dette vil samtidig også kunne åpne for at ressurssvake menneskegrupper enklere får tilgang til digitale medier, fordi det ikke lenger vil kreve dyr og ny maskinvare. Det fremstår i dag som en drøm å kunne være i stand til å tilby en løsning som jevner ut klasseforskjeller på verdensbasis, og gi flere mennesker muligheter til å ta del i informasjonsfellesskapet internett. Vi mener at dette burde være en faktor man fokuserer på i større grad ved fremtidig utvikling av programvare, og vi tror at selv prosjekter som vårt, som er små i denne store sammenhengen, likevel kan bidra til endringer på sikt. 94

95 Bibliografi Skybaserte løsninger: - Danielson, K. (2008, 03 26). Distinguishing Cloud Computing from Utility Computing. Hentet 01 15, 2010 fra ebizq - The insider's Guide to Business and IT Agility: - King, R. (2008, 08 04). Cloud Computing: Small Companies Take Flight. Hentet 01 17, 2010 fra Bloomberg Businessweek: Amazon EC2: - Amazon Web Services LLC. (2010). Amazon EC2 Facts and Questions. Hentet 01 15, 2010 fra Amazon EC2 FAQs: - Amazon Web Services LLC. (2010). Amazon Web Services. Hentet 01 10, 2010 fra Amazon Web Services: - Jiang Dejun, G. P.-H. (2009, 11). EC2 Performance Analysis for Resource Provisioning of Service-Oriented Applications. Hentet 02 02, 2010 fra DynDNS: - Dynamic Network Services Inc. (2010). DynDNS.com. Hentet 01 22, 2010 fra - Dynamic Network Services Inc. (2010). DynDNS.com. Hentet 01 23, 2010 fra What is DNS?: 95

96 Virtuelle maskiner: - Sing, A. (2004, 01). kernelthread.com. Hentet 02 05, 2010 fra An Intruduction to Virtualization: Renderfarm: - Tait, M. (2005, 05 01). Extreme Tech - Build it,tweak it, Know it. Hentet 17 12, 2009 fra Xen: - Citrix Systems, Inc. (2010). Xen. Hentet 01 29, 2010 fra What is Xen?: - HowtoForge - Linux Howtos and Tutorials. (2010). HowtoForge - Linux Howtos and Tutorials. Hentet 02 03, 2010 fra MLN: - Kyrre Begnum, J. S. (2009, 11 04). The MLN Manual. Hentet 01 11, 2010 fra Parallell databehandling: - Barney, B. (2010). Introduction to Parallel Computing. Hentet 04 10, 2010 fra Lawrence Livermore National Laboratory: - Utdanningsdirektoratet. (2008). IKT i skolen. Hentet 03 29, 2010 fra Loven om avtagende grensenytte: pslanguage=no - Amdahl, G. (1967). Validity of the single processor approach to achieving large scale computing capabilities. Hentet 04, 2010 fra AFIPS spring joint computer conference, 1967: 96

97 Grafikkprosessering: - Cornwell University Program of Computer Graphics. (u.d.). What is Computer Graphics? Hentet 02 11, 2010 fra Blender: - Blender. (2010). Blender.org. Hentet 02 17, 2010 fra - Blender. (2010). Doc:Manual/Introduction. Hentet 02 13, 2010 fra DrQueue: - DrQueue. (2010). DrQueue, the Open Source Distributed Render Queue. Hentet 02 03, 2010 fra Introducing DrQueue the Distributed Render Queue Manager: Det juridiske aspektet: - Datatilsynet. (2010). Datatilsynet. Hentet 04 05, 2010 fra 3.aspx - Rønning, A. j. (2010, 05 07). Advokat bladet. Hentet 05 17, 2010 fra Komplisert jus i nettskyen: - Smith, B. (2010, 01 20). General Counsel, Microsoft Corporation. Hentet 04 24, 2010 fra NFS: - The Linux Documentation Project. (2010). Linux NFS-HOWTO. Hentet 02 03, 2010 fra - Indiana University. (2010). University Information Technology Services. Hentet 02 04, 2010 fra Knowledge Base - What is NFS?: 97

98 Metode: - Edwardsson, B. (2008, 03 06). Rättssäkerhetsorganisationen. Hentet 03 18, 2010 fra Vad är sakligt utredningsarbete: - Gunnarsson, R. (2007, 01 05). Kunskapsanats - kvalitativt eller kvantitativt perpektiv? Hentet 03 19, 2010 fra - Åsberg, R. (2001). Pedagogisk Forskning i Sverige. Hentet 03 20, 2010 fra Miljø: - Electronic TakeBack Coalition. (2010, 03). Facts and Figures on E-Waste and Recycling. Hentet 04 16, 2010 fra - Greenpeace. (2010). Greenpeace International. Hentet 03 24, 2010 fra IT can help solve climate change: Eksisterende løsninger: - vswarm. (2010). vswarm. Hentet 03 12, 2010 fra 98

99 Forklaringer Her følger noen korte forklaringer av noen begreper. De fleste nøkkelbegrepene vi bruker i dette prosjektet er beskrevet i bakgrunnskapittelet, eller etter hvert som det er naturlig i teksten. Forklaringene nedenfor er ment som et hjelpemiddel for bedre forståelse av rapporten. 3D grafikk Termen 3D grafikk brukes generelt om å gjenskape bilder som skaper en illusjon av dybde med bruk av en datamaskin. Applikasjon En applikasjon er et dataprogram som passer til et visst system. Applikasjonen arbeider mot systemet og utnytter dens resurser for å utføre tenkt oppgave Animasjon En animasjon er en rad med tegnede bilder som utgjør en bevegelse. Dette er en mye brukt teknikk i filmer og serier. Et godt eksempel på en animert film er for eksempel Toy Story. Amazon EC2 Amazon EC2 er en stor serverpark der både privatpersoner og foretak kan leie forskjellige typer instanser. De forskjellige instanstypene har varierende prestasjonsnivå hvilket innebærer at man betaler for det man bruker. Cloud Computing Se Sky Datasystem Et datasystem kan bestå av en hjemme PC eller en server. Et system er en rad fungerende datakomponenter som til sammen skaper ett fungerende datasystem. Drifting For å holde en Server eller Serverpark gående, behøver den å opprettsholdes. Dette gjennomføres ved å drifte serveren. Hardware Hardware er det samme som fysisk maskinvare, og er alle komponentene som sitter i en PC, Server og annet elektronisk utstyr som styres av en 99

100 datamaskin. Når det kommer til datamaskiner handler det ofte eksempelvis om harddisker, prosessorer, ram minne og alle de andre komponentene som sitter eksempelvis i en datamaskin. Hjemmemaskin En hjemmedatamaskin er en datamaskin som er sammenlignbar med en vanelig allmenn datamaskin som kan finnes i enhver normal husholdning Hypervisor En hypervisor er et program som tillater flere ulike operativsystem og kjøre på samme partisjon. Den fordeler til og med CPU og kontrollerer star og stopp av de virtuelle maskinene som jobber i samme prosessmiljø. Lokal Server En lokal server er en server som er plassert innenfor ditt lokale nettverk. Nettverk Et nettverk består av flere like eller ulike dataelement som er linket sammen enten via en kabelløsning eller en trådløst. Prosessorkraft Prosessorkraft er betegnelsen på hvor mye et datasystem maskin kan yte i utregningskraft. Hvor rask en prosessor kan utregne måles i svingninger per sekund (Hz). I dag er det veldig vanelig at en prosessor kan utføre utregninger opp til 3.2GHz ( Hz). Renderfarm En kobling av flere maskiner som jobber med en oppgave. I grafikkprosessering vil en renderfarm jobbe mot å gjenskape gitt bilde. Sensitiv data Sensitiv data er data som kan oppfattes som skadelig eller følsom for noen. Det er et veldig brett område da visse data kan være av ingen verdi for en gruppe og samtidig veldig viktige for en annen gruppe. Server En kraftfull data som er utviklet for mer for å arbeide og mindre for underholdning. En server kan foreksempel håndtere en bedrifts e-post konto eller deres internettverk. En server fungerer ofte som hjernen i et nettverk. Serverpark En serverpark er mange servere sammenkoblet for og nå et høyere ytelsesnivå og lagringskapasitet. 100

101 Hypervisor En hypervisor er et program som tillater flere ulike operativsystem og kjøre på samme partisjon. Den fordeler til og med CPU og kontrollerer star og stopp av de virtuelle maskinene som jobber i samme prosessmiljø Sky-tjeneste En sky i IT-sammenheng er egentlig et begrep som omhandler at man arbeider et sted som øyet ikke kan se. Sky-tjeneste handler om at man kan koble seg opp mot et datanettverk via internett og benytte datakraft fra dette nettverket. 101

102 Vedlegg 1 Fremdriftsplan 102

103 Vedlegg 2 Design Dette designdokumentet har i hovedsak tre fokusområder. Det skal: tydeliggjøre hva som skal utarbeides og undersøkes, ved å tydeliggjøre mål, sett i forhold til problemstilling og kravspesifikasjon. beskrive hvordan undersøkelsen kan gjennomføres og hvordan resultatene skal vurderes i forhold til kravspesifikasjon vise at undersøkelsen er gjennomførbar ved å vise til forventede funn og peke på risikoer ved gjennomføringen Vi har valgt å designe fremgangsmåte ved å sette opp delmål i et strukturert skjema: Design A: Testlab (Mål A.1, A.2, A.3) Design B: Sky (Mål B.1) Design C: Undersøkelse (Mål C.1, C.2, C.3, C.4), Hvert mål er et eksperiment eller en oppgave vi skal gjennomføre i prosjektet. Hvert mål blir vurdert i forhold til: - Hva ønsker vi å oppnå med undersøkelsen/eksperimentet? - Hva ønsker vi å finne ut? - Hva må man ha for å kunne gjennomføre undersøkelsen/eksperimentet? - Hva skal målestokken være? - Hva er forutsetning for å kunne gjennomføre undersøkelsen? - Hvilken metode skal vi bruke for å innhente dataene? - Hvilke konklusjoner kan vi forvente å trekke? - Hvilken faglig og administrativ usikkerhet finnes i designet og prosjektplanen? I tillegg til presentasjonen av Design A og B, blir hvert mål presentert mer inngående i kapittel 2 Designmålene, med fremgangsmåte, betingelse og målestokk. Til enkelte av målene, finnes også undermål. 103

104 Designdel A: Prototype Hva Hvordan Gjennomførbarhet Mål Problemstilling Målestokk Krav til undersøkelsen Metode Forventede funn Gjennomføringsrisiko Hva ønsker vi å oppnå med undersøkelsen? Hva ønsker vi å finne ut? Hva skal målestokken være? Hva er forutsetningene for å kunne gjennomføre undersøkelsen Hvilken metode skal vi bruke for å innhente dataene? Hvilke konklusjoner kan vi forvente å trekke? Hvilken faglig og administrativ usikkerhet finnes i designet og prosjektplanen? Mål A.1: Få til en fungerende infrastruktur med noder som kommuniserer Lage et nettverk med virtuelle maskiner som kommuniserer. Når vi har en løsning som virker stødig og forutsigbar lokalt En server og programvare (operativsystem, Xen hypervisor, MLN), og script som kobler sammen nodene. Forventer at vi får en klynge med kommuniserende noder opp. - Lavt teknisk nivå i gruppen - Sykdom og dårlig kommunikasjon i gruppen Mål A.2: Utføre en grafikkprosessering lokalt Fungerer alt? Å ha testet renderfarmen grundig lokalt. Installasjon av Blender, NFS og DrQueue i filsystem for mester og slavenode. At renderfarmen fungerer tilfredsstillende nok til at den kan testes på sky. - Lavt teknisk nivå i gruppen - Sykdom og dårlig kommunikasjon i gruppen 104

105 Mål A.3: Få til å sende en renderfarm ut på en sky (Amazon EC2) og utføre en prosesseringsoppgave. Fungerer det like godt på sky som lokalt? Når en konkret jobb blir utført på sky En forbindelse med Amazon EC2 må det skaffes en lisens, samt vi må legge til EC2 pluginet og justere litt i MLN-filen for prosjektet. Skaffe lisens og ved hjelp av kommandolinje å sende en oppgave ut på Amazon Forventer at vi får det til og at det fungerer. - Lavt teknisk nivå i gruppen Sykdom og dårlig kommunikasjon i gruppen 105

106 Designdel B: Undersøkelse og testing (fase 1, 2, 3 og 4) Hva Hvordan Gjennomførbarhet Mål Problemstilling Målestokk Krav til undersøkelsen Metode Forventede funn Gjennomføringsrisiko Hva ønsker vi å oppnå med undersøkelsen? Hva ønsker vi å finne ut? Hva skal målestokken være? Hva er forutsetningene for å kunne gjennomføre undersøkelsen Hvilken metode skal vi bruke for å innhente dataene? Hvilke konklusjoner kan vi forvente å trekke? Hvilken faglig og administrativ usikkerhet finnes i designet og prosjektplanen? Mål B.1: Utforme undersøkelsene For å klare å gjennomføre gode eksperimenter som gir et godt underlag for vurdering All bakgrunnsmaterialer til eksperimentene skal være klare Vi trenger måleverktøy, fil som skal prosesseres, og mal for vitenskaplig testing. Samhandles om oppgaven, og prøve å bruke vitenskapelig standard Undersøkelser som holder vitenskapelig standard At testene ikke har tilfredsstillende kvalitet. 106

107 Mål B.2: Lage metodene og verktøyene for undersøkelsene Ønsker å finne/lage de beste verktøyene/ metodene for å kunne måle nøyaktig, slik at resultatet blir pålitelig verktøy/metoder skal måle - Ytelse (hvor mange sekunder oppgaven tar) - Kvalitet (måle CPU i nodene) - Kostnad/pris Vi må kunne lage målescript, evt. finne gode verktøy Lage script for måling av CPU, tid og nettverksbelastning. At vi ikke klarer å lage eller finne gode nok verktøy/metoder Mål B.3: Gjennomføre test For å få resultater vi kan vurdere Når vi har fått inn all data og eksperimentene er gjennomført slik vi hadde tenkt Godt utformede undersøkelser og godt utprøvde verktøy/metoder Innsamling av data ved gjennomføring av test Gode og nøyaktige testresultat Problemer med målinger som gir unøyaktige data Mål B.4: Vurdere data Se om dataen samsvarer med prosjektets problemstilling All data har blitt prosessert og gjort om til konkrete funn ved hjelp av grafer og tabeller. All data er tilgjengelig. 107

108 Designmålene Dette kapitlet inneholder en presentasjon av hvert mål. Målene er lagt inn i skjema med feltene: fremgangsmåte, betingelse og målestokk. Til enkelte av målene, finnes også undermål. 2.1 Mål A Prototype Mål A.1: Sette opp en server, installere programvare og lage nødvendige script. Med dette målet ønsker vi å sette opp en server, installere nødvendig programvare og lage et MLN prosjekt med noder som kommuniserer. Framgangsmåte og forutsetning: Sette opp server Installere serverprogramvare og konfigurere nettverk så vi har tilgang til internett. Installere Xen Xen programvare. Installere MLN MLN programvare. Få de ulike elementene til Et script som sørger for at mesternode skal kunne koble opp og å kommunisere kommunisere med slavenodene. Målestokk Hovedmål: Å skape en fungerende infrastruktur. Mål A.2: Få renderfarm til å fungere lokalt Med dette målet ønsker vi å få en renderfarm til å kjøre lokalt, slik at vi kan teste systemet grundig før vi prøver sende det på sky. Framgangsmåte og forutsetning: Installasjon av NFS NFS programvare Installasjon av Blender Blender programvare Installasjon av DrQueue DrQueue programvare Mål A.1 (Testlab) Må ha satt opp en infrastruktur(mål A.1) Målestokk Hovedmål: Å ha en fungerende renderfarm kjørende lokalt og teste denne ved å utføre en grafikkprosessering. 108

109 Mål A.3: Få til å sende en renderfarm ut på en sky (Amazon EC2) Med dette målet ønsker vi å sende renderfarmen ut på en sky og utføre en grafikkprosessering. Framgangsmåte og betingelse: Hele Designmål A må være Vi må kunne ha en renderfarm som fungerer godt lokalt. gjennomført Lisens for Amazon EC2 Vi må være registrert/inneha en lisens for Amazon EC2 for å kunne (sky) benytte deres sky i våre undersøkelser. Målestokk Hovedmål: Når vi har klart å sende renderfarmen ut på Amazon EC2, og få den til å utføre flere grafikkprosesseringsoppgaver og vise en viss forutsigbarhet. 2.3 Mål C Undersøkelse Mål B.1: Utforme undersøkelsene Med dette målet ønsker vi å utforme undersøkelsene vi skal utføre i prosjektet. Hva vil vi undersøke? Hvordan skal vi gjøre det? Hvorfor skal vi gjøre det på denne måten? Hvilke målinger må vi utføre og hvor mange antall ganger? Framgangsmåte og betingelse: Hele Designmål A og B må Vi må flere ganger ha gjennomført en vellykket grafikkprosessering være gjennomført ved bruk av den lokale renderfarmen, samt hatt flere suksessfulle gjennomføringer av å sende renderfarmen ut på en sky. Testbok Vi må ha en testbok, som inneholder klare mål for hva vi ønsker å undersøke og hvilke krav som må oppfylles for at en undersøkelse holder høy nok kvalitet. Vi må sette opp gode beskrivelser av hva, hvorfor og hvordan vi skal utføre undersøkelsene, slik at vi har konkrete mål når vi skal utarbeide målescriptene og metodene som skal brukes i testingen Mål C.1.1, C.1.2, C.1.3, Vi må ha god oversikt over hva vi ønsker å undersøke C.1.4 og C.1.5 må være ferdig Målestokk Hovedmål: Utforme alle undersøkelsene (oversikt over hva, hvordan og hvorfor) Hva skal vi måle? Ytelse Kostnader Kvalitet/ pålitelighet 109

110 Annet (for eksempel: Mengde teknisk kompetanse bedriften bør ha tilgjengelig) Hvorfor? Alle disse målingene er viktige for at vi skal kunne foreta undersøkelsene i prosjektet og imøtekomme problemstillingen i prosjektet. Det er viktig å ha en plan til utformingen av tester/ undersøkelser osv slik at vi har god oversikt over hva vi vil finne ut, hvorfor og hvordan. Mål B.1.1: Ytelse Hvor lang tid tar det å utføre en grafikkprosessering med svake virtuelle maskiner? Hvor lang tid tar det å utføre en grafikkprosessering på kraftige virtuelle maskiner i en sky? Framgangsmåte og betingelse: Hente ut data om tidsbruk Dette måles via informasjonen vi kan hente ut fra DrQman (brukergrensesnittet til DrQueue). Gjennomføre gjentatte Ved å gjennomføre gjentatte forsøk, prøve ulike filstørrelser for forsøk grafikkprosessering, og ulike antall noder. Sjekke dette ut både lokalt og på en sky og undersøke hvor pålitelig og forutsigbart systemet er Målestokk Hovedmål Utforme hvordan vi skal hente ut gode underlagstall om ytelse for bruk til undersøkelsen Mål B.1.2: Hvor lang tid tar det å gå fra lokal til nettskybasert renderfarm? Hvor pålitelig er nettskyløsningen? Framgangsmåte og betingelse: Lage script Script som tar tiden på hvor land tid det tar å sende ut et prosjekt på sky til forskjellige tider av døgnet, samt tar tiden fra prosjektet startes, til mesternoden kan pinges. Målestokk Hovedmål Hente ut gode underlagstall til undersøkelsen 110

111 Mål B.1.3: Kostnader Hva er kostnadene i forbindelse med bruk av en skybasert renderfarm? Strømkostnader? Lisens? Tid? Sammenligne kostnadene: Sky-basert renderfarm, lokal renderfarm og egen Renderfarm med flere noder. Finne grensen for når det begynner/slutter å bli lønnsomt å bruke vår løsning Framgangsmåte og betingelse: innhente priser på Finne priser på maskinvare, tilsvarende en renderfarm med virtuelle maskinvare maskiner på sky Innhente priser på lisenser Få oversikt over kostnadene knyttet til de forskjellige ytelsesløsningene Amazon EC2 har å tilby. Målestokk Hovedmål Hente ut representative og realistiske tall, samt sammenligne kostnader knyttet til forskjellige renderfarmløsninger. Mål B.1.4: Kvalitet/ pålitelighet Klarer nodene å yte maksimalt med grafikkprosesseringsoppgaven? Hvor god ytelse har vi? Har vi mye bildetap? Hvor ligger begrensningene? Framgangsmåte og betingelse: Plan for å lage script Overvåkning av antall bytes inn og ut på porter (DrQueue og NFS) Avlesning av DrQman Undersøke grad av bildetap Plan for totalvurdering Målestokk Hovedmål Utforme en plan for hvordan vi skal hente ut gode underlagstall om kvalitet og pålitelighet Mål B.2: Lage metodene og verktøyene for undersøkelsene (lage script) Med dette målet ønsker vi å lage de konkrete scriptene/verktøyene som skal brukes for å gi det nødvendige underlagsmaterialet vi trenger for undersøkelsen. Framgangsmåte og betingelse: Mål C.1 må være Vi må ha veldefinerte mål og ideer om hvordan vi skal gjennomføre 111

112 gjennomført Kunnskap om hvor vi finner data Målestokk Delmål 1: Delmål 2: Hovedmål: undersøkelsene, hva vi ønsker å finne ut og hvorfor vi trenger denne informasjonen, slik at vi kan lage script som henter ut riktig informasjon som kan brukes som materiale for vurdering i undersøkelsen. Vi må ha kunnskap om hvor vi finner riktig data slik at vi får ut meningsfull informasjon Lage script for målinger Teste at scriptene gir korrekte måleresultater, for å få mest mulig korrekt materiale til undersøkelsen. Alle nødvendige script og måleverktøy må være klare i forkant av testingen Mål B.3: Gjennomføre testene Med dette målet ønsker vi å gjennomføre undersøkelsene /testene ut fra de planer og med bruk av de målingsverktøyene vi har klargjort i Mål C.1 og C.2. Framgangsmåte og betingelse: Mål C.1 og C.2 må være Vi må ha en god plan med klare beskrivelser av hvordan vi skal gjennomført og ferdig gjennomføre testingen. Testingen bør ha vært forsøkt tidligere. Sette av tid, ressurser og Det er viktig med godt forarbeid slik at man midtveis i testingen ikke nødvendig rendertoppgave blir nødt til å gjøre justeringer som kan føre til at resultatet ikke blir til gjennomføring av riktig. testing Målestokk Hovedmål: Sitte igjen med masse gode tallmaterialer/resultater som vi kan bruke for å sammenstille og vurdere Mål B.4: Vurdere data Med dette målet ønsker vi å ha et klart resultat av testene og gjennomføre grundig sammenstilling og vurdering Framgangsmåte og betingelse: Mål C.1 må være Vi må ha helt klare mål og ideer om hvordan vi skal gjennomføre gjennomført undersøkelsene, hva vi ønsker å finne ut og hvorfor vi trenger denne 112

113 Kunnskap om hvor vi finner data Målestokk Hovedmål: informasjonen, slik at vi kan lage script som henter ut riktig informasjon som kan brukes som materiale for vurdering i undersøkelsen. Vi må ha kunnskap om hvor vi finner riktig data slik at vi får ut riktig informasjon Foreta gode vurderinger av testresultatene basert på gode rådata 113

114 Vedlegg Script Script for mesternoden #!/usr/bin/perl use Socket; ##### HENTER EGEN IP ##### open (my $IFCONFIG, "ifconfig head -2 grep inet ") or die "Could not open ifconfig!\n"; while (my $line=<$ifconfig>) { = split/\s+/, $line; $array[2] =~s/addr://; my $ip = $array[2]; system("master &"); ###### SOCKET ###### my $buffersize = 2048; my $port = 45000; my $proto = getprotobyname('tcp'); my $NFS_CONFIGURED = 0; socket(server, PF_INET, SOCK_STREAM, $proto) or die "socket: $!"; setsockopt(server, SOL_SOCKET, SO_REUSEADDR, 1) or die "setsock: $!"; my $paddr = sockaddr_in($port, INADDR_ANY); bind(server, $paddr) or die "bind: $!"; listen(server, SOMAXCONN) or die "listen: $!"; print "SERVER started on port $port\n"; while (my $client_addr = accept(client, SERVER)) { my ($client_port, $client_ip) = sockaddr_in($client_addr); my $client_ipnum = inet_ntoa($client_ip); print "Clients IP: [$client_ipnum]\n"; my $data; recv(client, $data, $buffersize, 0); print $data, "\n"; $data =~ /(\S+)\s+(\S+)/; my $client_ip = $1; my $client_netmask = $2; print "client reported IP: $client_ip with netmask: $client_netmask\n"; if ( not $NFS_CONFIGURED ){ open(nfs,">/etc/exports"); $client_ip =~ s/\.(\d+)$/0/; 114

115 my $octet = $client_ip; $octet =~ s/^(\d+)\..*/$1/g; if ( $octet == 10 ){ $client_ip = " "; $client_netmask = " "; } print NFS "/mnt $client_ip/$client_netmask (rw,sync,no_root_squash)\n"; close(nfs); system("/etc/init.d/nfs-user-server restart"); $NFS_CONFIGURED = 1; } send(client, "$ip", 0); close CLIENT; } } 115

116 Script for slavenoden #!/usr/bin/perl use Socket; if ($ARGV[0]) { open (my $IFCONFIG,"ifconfig head -2 grep inet ") or die "Can't open ifconfig!\n"; while (my $line = <$IFCONFIG>) { /\w+\:/, $line; my $ip="$array[1]$array[3]"; ######### SOCKET ######### while(1) { my $host =$ARGV[0]; my $port = 45000; my $proto = getprotobyname('tcp'); my $iaddr = inet_aton($host); my $paddr = sockaddr_in($port, $iaddr); socket(socket, PF_INET, SOCK_STREAM, $proto) or die "socket: $!"; if (connect(socket, $paddr)) { send SOCKET, "$ip", 0; my $line; recv(socket, $line, 15, 0); print $line, "\n"; system ("mount -t nfs $line:/mnt /mnt"); if(stat("/mnt/mount-success")) { print "Mount-success!\n"; system("export DRQUEUE_MASTER=$line; slave &"); } else { print "Mount error!\n";} close SOCKET or die "close: $!"; exit 0; } else { redo; } } } }else{print "Argument required (ex: myfront.dnsalias.org)\n";} 116

117 3.2 MLN-fil Eksempelet viser 4 slavenoder c1.xlarge, Sone US global { project 4XL } autoenum { numhosts 4 superclass rendernode hostprefix node } project_password ec2rocks superclass common { xen extra xencons=tty root_passwd XXX ec2 { type c1.xlarge mount1 /mnt/drqueue/output } memory 512 network eth0 { address dhcp } sshkey { mroot ssh-dss XXXXXXXXXXXXXX mroot ssh-dss XXXXXXXXXXXXXX } users { mroot XXX } root_passwd XXX template nyslave_small.ext3 } superclass rendernode { superclass common } ec2 { use node1 quickbuild startup { depmod -a export PATH=$PATH:/mnt/drqueue/bin export DRQUEUE_ROOT=/mnt/drqueue export DRQUEUE_MASTER=renderfront.dyndns.org /root/slave_connect.pl renderfront.dyndns.org } 117

118 } host front { boot_order 1 ec2 { type c1.xlarge } superclass common template nymester_small.ext3 dyndns { hostname XXX user XXX password XXX } startup { depmod -a export PATH=$PATH:/mnt/drqueue/bin export DRQUEUE_ROOT=/mnt/drqueue export DRQUEUE_MASTER= cd /root/drqueue scons prefix=/mnt install /root/master_connect.pl } } 118

119 Eksempelet viser 2 slavenoder m1.small, Sone EU global { project 2SMALL } autoenum { numhosts 2 superclass rendernode hostprefix node } project_password ec2rocks superclass common { xen extra xencons=tty root_passwd XXX ec2 { type m1.small region EU zone eu-west-1a mount1 /mnt/drqueue/output } memory 512 network eth0 { address dhcp } sshkey { mroot ssh-dss XXXXXXXXXXXXXXXXX mroot ssh-dss XXXXXXXXXXXXXXXXX } users { mroot XXX } root_passwd XXX template nyslave_small.ext3 } superclass rendernode { superclass common } ec2 { use node1 quickbuild startup { depmod -a export PATH=$PATH:/mnt/drqueue/bin export DRQUEUE_ROOT=/mnt/drqueue export DRQUEUE_MASTER=renderfront.dyndns.org /root/slave_connect.pl renderfront.dyndns.org } 119

120 } host front { boot_order 1 ec2 { type m1.small } superclass common template nymester_small.ext3 dyndns { hostname XXX user XXX password XXX } startup { depmod -a export PATH=$PATH:/mnt/drqueue/bin export DRQUEUE_ROOT=/mnt/drqueue export DRQUEUE_MASTER= cd /root/drqueue scons prefix=/mnt install /root/master_connect.pl } } 120

121 3.3 Testscript Testscript for måling av byggetid #!/bin/bash start1=$(date +%s); echo "Start point for build: $start1"; mln build -f 2slaver.mln -r stop1=$(date +%s); date >> PUSH-PING-RESULTATER echo "Sone US" >> PUSH-PING-RESULTATER echo "$stop1 - $start1" bc >> PUSH-PING-RESULTATER start2=$(date +%s); echo "Start point for build: $start1"; mln build -f 2slaver_EU.mln -r stop2=$(date +%s); date >> PUSH-PING-RESULTATER echo "Sone EU" >> PUSH-PING-RESULTATER echo "$stop2 - $start2" bc >> PUSH-PING-RESULTATER Testscript for måling av Pingtid #!/bin/bash host="render.dyn-o-saur.com"; wait=5 start=$(date +%s); mln start -p 2slaver echo "start point: $start, host: $host"; while! ping -W 1 -c 2 $host ; do echo "Ping failed, waiting $wait seconds, before retry"; sleep 3 host $host done echo "Host is online"; stop=$(date +%s) echo -n "time: "; $start >> PUSH-PING-RESULTATER echo "$stop - $start" bc >> PUSH-PING-RESULTATER echo "$stop - $start" bc >> ping-res mln stop -p 2slaver echo "TESTEN ER FERDIG!"; 121

122 Testscript for måling av bedlastningstid #!/bin/bash date >> SCP-RESULTATER start=$(date +%s); scp stop=$(date +%s); echo "$stop - $start" bc >> SCP-RESULTATER mln stop -p 1_SMALL echo "Test finished"; 122

123 Vedlegg 4 Testbok Innledning: Denne testboken gir en oversikt over de tester og undersøkelser vi har utført for å kunne svare på problemstillingen i dette prosjektet. Selve testboken begynner på side 128, der hver test er presentert med navn, nummer og sidetall. Hver test kan bestå av flere undertester som representerer variasjoner innenfor samme test. Det kan for eksempel være ulike antall noder, eller variasjoner i forhold til når på døgnet man utfører testen. For å gi en bedre oversikt over utførte tester, har vi laget en oversikt som viser et sammendrag av hva vi har testet, hvorfor vi har testet dette og hvordan. Hver test er bygget opp rundt disse spørsmålene. Selve testboken er lagt inn som en innholdsfortegnelse, slik at man ved å klikke på testen i testboken, kan gå direkte til riktig side i testboken. 123

124 En oversikt over testene som er gjennomført: Hva? Hvorfor? Hvordan? Testens navn: Variasjoner (deltester): Hensikten med testen Hvordan er målingene gjort: 1. Måle tiden og døgnvariasjon på en grafikkprosesseringsoppgave på EC2, sone US, regionstype c1.small Døgnvariasjoner, med tidtaking hver klokketime i 24 timer 1.1 Måle tiden på en grafikkprosesseringsoppgave, 2 noder, EC2 US East 1.2 Måle tiden på en grafikkprosesseringsoppgave, 4 noder, EC2 US East Måle ytelse og pålitelighet på EC2 US Bruke DrQman brukergrensesnitt for grafikkprosessering av fil, og lese av tiden som er brukt. 2. Måle tiden og døgnvariasjon på en grafikkprosesseringsoppgave på EC2, sone EU, regionstype c1.small Døgnvariasjoner, med tidtaking hver klokketime i 24 timer 2.1 Måle tiden på en grafikkprosesseringsoppgave, 2 noder, EC2 region EU 2.2 Måle tiden på en grafikkprosesseringsoppgave, 4 noder, EC2 region EU Måle ytelse og pålitelighet på EC2 EU Bruke DrQman brukergrensesnitt for grafikkprosessering av fil, og lese av tiden som er brukt. 3. Måle tiden det tar å bygge, sende, starte og pinge et MLN prosjekt ut på en sky Døgnvariasjoner i forhold til tiden det tar å bygge et MLN prosjekt og tiden det tar før en node kan nås med ping med tidtaking hver klokketime i 24 timer (3.1) og tidtaking hver fjerde klokketime i 48 timer (3.2): 3.1 Måle tiden det tar å bygge, sende, starte og pinge et MLN prosjekt ut på en sky ( byggstart til ping ) Se på forutsigbarhet og pålitelighet på EC2 US og EU Script: Resultater fra byggstart-tilping -script, som kjøres automatisk og skriver resultat til fil. 124

125 3.2 Måle tiden det tar å bygge, sende starte og pinge et MLN prosjekt ut på en sky ( byggstart til ping ) over en lengre periode (48 timer) Døgnvariasjon med tidtaking hver fjerde time i 2 x 24 timer: 3.3 Sammenligne og måle tiden det tar å bygge og sende et prosjekt ut på EC2 US og EC2 EU over en lengere periode 4. Grafikkprosessering av en stor fil, med økt antall noder. Er det samsvar mellom økt antall noder og kraft brukt i forhold til tid? (proporsjonalt / uproporsjonalt?) 1. Er det variasjoner i forhold til antall noder? Forutsigbarhet Finne informasjonen i DrQman 5. Måle nedlastningstid av isofil fra sky, til server over 24 timer. Evt. Variasjoner i forhold til størrelse på fil Script (scpscript) 6. Måling av pakketap under grafikkprosessering Kjøre iptables-scriptet samtidig med test 4. Variasjoner innenfor ulikt antall noder. For å se på kvalitet, pålitelighet, stabilitet Script: Iptables COUNT i loop med sleep, nulle ut chains ene etter hver kjøring og skrive resultat til fil med tidspunkt. 125

126 7. Tid det tar å starte et prosjekt til alle Amazon har allokert minne til alle noder 1. Er det variasjoner i forhold til antall noder? Bruke stoppeklokke fra man starter prosjektet, følge med på Amazonpanelet 8. Lokal grafikkprosessering med en slave 9. Kostnader (undersøkelser og vurderinger rundt kostnadsaspektet) Disse tre punktene er ikke en test, men mer en slags undersøkelse vi skal foreta som en del av vurderingen av løsningen Research, internett, Amazon Ikke alle testene nevnt i denne oversikten vil framstå som egne tester i testboken, da enkelte tester gir dataunderlag for flere typer undersøkelser og vurderinger. Våre undersøkelser omhandler flere dimensjoner, der enkelte av undersøkelsene eller vurderingene baseres på annen type research. 126

127 Testbokens innhold 1. Måle tiden på EC2 US fra start til stopp på en grafikkprosesseringsoppgave, 2 og 4 slavenoder, EC2 US East Måle tiden på en grafikkprosesseringsoppgave, 2 slavenoder, EC2 US East kl. 12: kl. 13: kl. 14: kl. 15: kl. 16: kl. 17: kl. 18: kl. 19: kl. 20: kl. 21: kl. 22: kl. 23: kl.0: kl. 1: kl. 2: kl. 3: kl. 4: kl. 5: kl. 6: kl. 7: kl. 8: kl. 9: kl. 10: kl. 11: Måle tiden på en grafikkprosesseringsoppgave, 4 slavenoder, EC2 US East kl. 12: kl. 13: kl. 14: kl. 15: kl. 16:

128 kl. 17: kl. 18: kl. 19: kl. 20: kl. 21: kl. 22: kl. 23: kl. 0: kl. 1: kl. 2: kl. 3: kl. 4: kl. 5: kl. 6: kl. 7: kl. 8: kl. 9: kl. 10: kl. 11: Illustrasjon av resultatene til test 1 (1.1 og 1.2): Testresultater (rådata) til test Testresultater (rådata) til test Måle tiden på EC2 EU fra start til stopp på en grafikkprosesseringsoppgave med 2 og 4 slavenoder, EC2 sone EU Måle tiden på en grafikkprosesseringsoppgave, 2 noder, EC2 sone EU kl. 12: kl. 13: kl. 14: kl. 15: kl. 16: kl. 17: kl. 18: kl. 19: kl. 20: kl. 21:

129 kl. 22: kl. 23: Måle tiden på en grafikkprosesseringsoppgave, 4 noder, EC2 sone EU kl. 12: kl. 13: kl. 14: kl. 15: kl. 16: kl. 17: kl. 18: kl. 19: kl. 20: kl. 21: kl. 22: kl. 23: Illustrasjon av resultatene til test 2 (2.1 og 2.2): Testresultater (rådata) til test Testresultater (rådata) til test Måle tiden det tar å bygge, starte og pinge et prosjekt på sky Måle tiden det tar å bygge, starte og pinge et renderfarmprosjekt på nettsky kl. 14: kl. 15: kl. 16: kl. 17: kl. 18: kl. 19: kl. 20: kl. 21: kl. 22: kl. 23: kl. 0: kl. 1: kl. 2: kl. 3: kl. 4:

130 kl. 5: kl. 6: kl. 7: kl. 8: kl. 9: kl. 10: kl. 11: kl. 12: kl. 13: Illustrasjon av resultatene til test 3.1: Måle tiden det tar å bygge, starte og pinge et renderfarmprosjekt på nettsky over 48 timer kl. 16: kl. 20: kl. 00: kl. 04: kl. 08: kl. 12: kl. 16: kl. 20: kl. 00: kl. 04: kl. 08: kl. 12: kl. 16: Illustrasjon av resultatene til test 3.2: Måle byggetiden parallelt mot Sone US og Sone EU apr. kl. 20: apr. kl. 00: apr. kl. 04: apr. kl. 08: apr. kl. 12: apr. kl. 16: apr. kl. 20: apr. kl. 04: apr. kl. 08:

131 apr. kl. 12: apr. kl. 16: apr. kl. 20: apr. kl. 00: apr. kl. 04: apr. kl. 08: Illustrasjon av resultatene til test 3.3: Måle tiden på grafikkprosessering av stor fil med ulike antall slavenoder, Sone US, instanstype c1.xlarge, og måling av bildetap Test 4XL - Måle tiden og bildetap på grafikkprosesseringsoppgave, 2 slavenoder XL nr XL nr XL nr XL nr Test 4XL - Måle tiden og bildetap på grafikkprosesseringsoppgave, 4 slavenoder XL nr XL nr XL nr XL nr Test 8XL - Måle tiden og bildetap på grafikkprosesseringsoppgave, 8 slavenoder XL nr XL nr XL nr XL nr Test 16XL - Måle tiden og bildetap på grafikkprosesseringsoppgave, 16 slavenoder XL nr XL nr XL nr XL nr Illustrasjon av resultatene til test 4: Testresultater (rådata) til test Måle nedlastningstid av en iso-fil fra node på nettsky, til server kl. 01: kl. 03:

132 5.3 - kl. 05: kl. 07: kl. 09: kl. 11: kl. 13: kl. 15: kl. 17: kl. 19: kl. 21: kl. 23: Illustrasjon av resultatene til test 5: Måling av trafikkmengde Tiden det tar å starte et renderfarmprosjekt lokalt til alle noder er oppe på Amazon EC Test 2XL - Måle tiden fra oppstart av renderfarmprosjekt til alle noder vises som oppe på Amazons kontrollpanel, 2 slavenoder test nr 1: 2XL test nr 2: 2XL test nr 3: 2XL Test 4XL - Måle tiden fra oppstart av renderfarmprosjekt til alle noder vises som oppe på Amazons kontrollpanel, 4 slavenoder test nr 1: 4XL test nr 2: 4XL test nr 3: 4XL Test 8XL - Måle tiden fra oppstart av renderfarmprosjekt til alle noder vises som oppe på Amazons kontrollpanel, 8 slavenoder test nr 1: 8XL test nr 2: 8XL test nr 3: 8XL Test 16XL - Måle tiden fra oppstart av renderfarmprosjekt til alle noder vises som oppe på Amazons kontrollpanel, 16 slavenoder test nr 1: 16XL test nr 2: 16XL test nr 3: 16XL

133 Illustrasjon av resultatene til test 8: Måle tiden det tar å grafikkprosessere en stor fil lokalt med en slave Undersøkelser knyttet til kostnader Strømforbruk

134 1. Måle tiden på EC2 US fra start til stopp på en grafikkprosesseringsoppgave, 2 og 4 slavenoder, EC2 US East 1.1 Måle tiden på en grafikkprosesseringsoppgave, 2 slavenoder, EC2 US East Test utført: 13. og 15. april, 12:00 Total varighet: 2 x 12 timer 12:00 Amazon EC2 Sone US East Antall slavenoder: 2 Grafikkprosesseringsfil: driven_hand.blend Bilder: 60 EC2 instanstype: m1.small Variasjoner innen hver klokketime på en hverdag: Test: Resultat: Test: Resultat: kl. 12:00 00:06: kl.0:00 00:06: kl. 13:00 00:06: kl. 1:00 00:06: kl. 14:00 00:06: kl. 2:00 00:06: kl. 15:00 00:06: kl. 3:00 00:06: kl. 16:00 00:06: kl. 4:00 00:06: kl. 17:00 00:06: kl. 5:00 00:06: kl. 18:00 00:07: kl. 6:00 00:06: kl. 19:00 00:06: kl. 7:00 00:07: kl. 20:00 00:06: kl. 8:00 00:06: kl. 21:00 00:06: kl. 9:00 00:06: kl. 22:00 00:06: kl. 10:00 00:06: kl. 23:00 00:08: kl. 11:00 00:06:42 134

135 1.2 Måle tiden på en grafikkprosesseringsoppgave, 4 slavenoder, EC2 US East Test utført: 13. og 15. april, 12:00 Total varighet: 2 x 12 timer 12:00 Amazon EC2 Sone US East Antall slavenoder: 4 Grafikkprosesseringsfil: driven_hand.blend Bilder: 60 EC2 instanstype: m1.small Variasjoner innen hver klokketime: Test: Resultat: Test: Resultat: kl. 12:00 00:03: kl. 0:00 00:04: kl. 13:00 00:03: kl. 1:00 00:03: kl. 14:00 00:03: kl. 2:00 00:03: kl. 15:00 00:04: kl. 3:00 00:06: kl. 16:00 00:03: kl. 4:00 00:03: kl. 17:00 00:03: kl. 5:00 00:03: kl. 18:00 00:04: kl. 6:00 00:03: kl. 19:00 00:03: kl. 7:00 00:03: kl. 20:00 00:03: kl. 8:00 00:03: kl. 21:00 00:03: kl. 9:00 00:03: kl. 22:00 00:03: kl. 10:00 00:03: kl. 23:00 00:03: kl. 11:00 00:04:05 135

136 Illustrasjon av resultatene til test 1 (1.1 og 1.2): Diagrammet viser døgnvariasjon i løpet av to ukedager, over hvor lang tid det tar å grafikkprosessere en fil på EC2 sone US. Sammenligning av grafikkprosesseringstid på 2 og 4 slavenoder - Sone US Tid 00:08:38 00:07:12 00:05:46 00:04:19 00:02:53 2 slavenoder 4 slavenoder 00:01:26 00:00:00 Klokkesklett Diagrammet viser døgnvariasjon over hvor lang tid det tar å grafikkprosessere en fil på EC2 sone US East, og sammenligner reelle tall med de resultatene DrQueue gir som gjennomsnittstid. DrQueue presenterer gjennomgående bedre gjennomsnittlige resultater enn de faktiske resultatene. Tid 00:08:38 Sammenligning av reelle grafikkprosesseringstider med DrQueue sine gjennomsnittsresultater, Sone US 00:07:12 00:05:46 00:04:19 00:02:53 2 slavenoder Gj.snitt DrQ 2 slavenoder 4 slavenoder Gj.snitt DrQ 4 slavenoder 00:01:26 00:00:00 Klokkeslett 136

137 Testresultater (rådata) til test 1.1 Amazone Antall Img. Antall Submission Finish Gj. frame Kontroll Frames Dag Tidspunkt EC2 Fil frames template slaver time time Totaltid tid av sn.tid failed: 13.apr 12:00 USA East driven_hand.blend 60 m1.small 2 12:02:58 12:09:38 00:06:40 00:00:13 00:06: apr 13:00 USA East driven_hand.blend 60 m1.small 2 12:58:32 13:05:15 00:06:43 00:00:13 00:06: apr 14:00 USA East driven_hand.blend 60 m1.small 2 14:04:57 14:11:36 00:06:39 00:00:13 00:06: apr 15:00 USA East driven_hand.blend 60 m1.small 2 15:03:19 15:09:45 00:06:26 00:00:12 00:06: apr 16:00 USA East driven_hand.blend 60 m1.small 2 16:00:58 16:07:18 00:06:20 00:00:12 00:06: apr 17:00 USA East driven_hand.blend 60 m1.small 2 17:04:40 17:11:11 00:06:31 00:00:12 00:06: apr 18:00 USA East driven_hand.blend 60 m1.small 2 18:23:23 18:31:15 00:07:52 00:00:15 00:07: apr 19:00 USA East driven_hand.blend 60 m1.small 2 19:06:30 19:13:12 00:06:42 00:00:13 00:06: apr 20:00 USA East driven_hand.blend 60 m1.small 2 20:03:38 20:10:02 00:06:24 00:00:12 00:06: apr 21:00 USA East driven_hand.blend 60 m1.small 2 21:07:37 21:14:15 00:06:38 00:00:13 00:06: apr 22:00 USA East driven_hand.blend 60 m1.small 2 22:16:32 22:23:02 00:06:30 00:00:12 00:06: apr 23:00 USA East driven_hand.blend 60 m1.small 2 23:01:31 23:09:39 00:08:08 00:00:15 00:07: apr 00:00 USA East driven_hand.blend 60 m1.small 2 00:01:17 00:07:53 00:06:36 00:00:13 00:06: apr 01:00 USA East driven_hand.blend 60 m1.small 2 01:06:05 01:12:51 00:06:46 00:00:13 00:06: apr 02:00 USA East driven_hand.blend 60 m1.small 2 02:00:28 02:07:09 00:06:41 00:00:13 00:06: apr 03:00 USA East driven_hand.blend 60 m1.small 2 03:14:48 03:21:27 00:06:39 00:00:13 00:06: apr 04:00 USA East driven_hand.blend 60 m1.small 2 04:02:56 04:09:31 00:06:35 00:00:13 00:06: apr 05:00 USA East driven_hand.blend 60 m1.small 2 05:03:21 05:09:46 00:06:25 00:00:12 00:06: apr 06:00 USA East driven_hand.blend 60 m1.small 2 06:09:44 06:16:35 00:06:51 00:00:13 00:06: apr 07:00 USA East driven_hand.blend 60 m1.small 2 07:00:17 07:07:28 00:07:11 00:00:14 00:07: apr 08:00 USA East driven_hand.blend 60 m1.small 2 08:07:45 08:14:31 00:06:46 00:00:13 00:06: apr 09:00 USA East driven_hand.blend 60 m1.small 2 09:05:03 09:11:31 00:06:28 00:00:12 00:06: apr 10:00 USA East driven_hand.blend 60 m1.small 2 10:00:04 10:06:42 00:06:38 00:00:13 00:06: apr 11:00 USA East driven_hand.blend 60 m1.small 2 11:06:03 11:12:45 00:06:42 00:00:13 00:06:

138 Testresultater (rådata) til test 1.2 Amazone Antall Img.templa Antall Submission Finish Gj. frame Kontroll Frames Dag Tidspunkt EC2 Fil frames te slaver time time Totaltid tid av sn.tid failed: 13.apr 12:00 USA East driven_hand.blend 60 m1.small 4 12:19:31 12:22:53 00:03:22 00:00:12 00:03: apr 13:00 USA East driven_hand.blend 60 m1.small 4 13:17:05 13:20:25 00:03:20 00:00:12 00:03: apr 14:00 USA East driven_hand.blend 60 m1.small 4 14:23:21 14:26:40 00:03:19 00:00:13 00:03: apr 15:00 USA East driven_hand.blend 60 m1.small 4 15:15:37 15:19:46 00:04:09 00:00:15 00:03: apr 16:00 USA East driven_hand.blend 60 m1.small 4 16:20:04 16:23:29 00:03:25 00:00:12 00:03: apr 17:00 USA East driven_hand.blend 60 m1.small 4 17:19:56 17:23:52 00:03:56 00:00:15 00:03: apr 18:00 USA East driven_hand.blend 60 m1.small 4 18:42:13 18:46:24 00:04:11 00:00:15 00:03: apr 19:00 USA East driven_hand.blend 60 m1.small 4 19:12:29 19:15:57 00:03:28 00:00:13 00:03: apr 20:00 USA East driven_hand.blend 60 m1.small 4 20:17:58 20:21:14 00:03:16 00:00:12 00:03: apr 21:00 USA East driven_hand.blend 60 m1.small 4 21:22:47 21:26:07 00:03:20 00:00:13 00:03: apr 22:00 USA East driven_hand.blend 60 m1.small 4 22:27:40 22:31:22 00:03:42 00:00:14 00:03: apr 23:00 USA East driven_hand.blend 60 m1.small 4 23:24:57 23:28:16 00:03:19 00:00:12 00:03: apr 00:00 USA East driven_hand.blend 60 m1.small 4 00:17:53 00:22:10 00:04:17 00:00:16 00:04: apr 01:00 USA East driven_hand.blend 60 m1.small 4 01:19:30 01:22:54 00:03:24 00:00:13 00:03: apr 02:00 USA East driven_hand.blend 60 m1.small 4 02:15:33 02:18:54 00:03:21 00:00:12 00:03: apr 03:00 USA East driven_hand.blend 60 m1.small 4 03:38:59 03:45:19 00:06:20 00:00:24 00:06: apr 04:00 USA East driven_hand.blend 60 m1.small 4 04:18:22 04:21:41 00:03:19 00:00:13 00:03: apr 05:00 USA East driven_hand.blend 60 m1.small 4 05:15:24 05:18:38 00:03:14 00:00:12 00:03: apr 06:00 USA East driven_hand.blend 60 m1.small 4 06:23:14 06:26:31 00:03:17 00:00:12 00:03: apr 07:00 USA East driven_hand.blend 60 m1.small 4 07:13:52 07:17:20 00:03:28 00:00:13 00:03: apr 08:00 USA East driven_hand.blend 60 m1.small 4 08:26:53 08:30:22 00:03:29 00:00:13 00:03: apr 09:00 USA East driven_hand.blend 60 m1.small 4 09:20:03 09:23:28 00:03:25 00:00:13 00:03: apr 10:00 USA East driven_hand.blend 60 m1.small 4 10:14:12 10:17:36 00:03:24 00:00:13 00:03: apr 11:00 USA East driven_hand.blend 60 m1.small 4 11:19:03 11:23:08 00:04:05 00:00:15 00:03:

139 2. Måle tiden på EC2 EU fra start til stopp på en grafikkprosesseringsoppgave med 2 og 4 slavenoder, EC2 sone EU 2.1 Måle tiden på en grafikkprosesseringsoppgave, 2 noder, EC2 sone EU Test utført: 21. april, 12:00 0:00 Total varighet: 12 timer Amazon EC2 Sone EU Antall slavenoder: 2 Grafikkprosesseringsfil: driven_hand.blend Bilder: 60 EC2 instanstyper: m1.small Variasjoner innen hver klokketime: Test: Resultat: Test: Resultat: kl. 12:00 00:06: kl. 18:00 00:06: kl. 13:00 00:06: kl. 19:00 00:06: kl. 14:00 00:06: kl. 20:00 00:06: kl. 15:00 00:06: kl. 21:00 00:06: kl. 16:00 00:07: kl. 22:00 00:06: kl. 17:00 00:06: kl. 23:00 00:06:27 139

140 2.2 Måle tiden på en grafikkprosesseringsoppgave, 4 noder, EC2 sone EU Test utført: 21. april, 12:00 0:00 Total varighet: 12 timer Amazon EC2 Sone EU Antall slavenoder: 4 Grafikkprosesseringsfil: driven_hand.blend Bilder: 60 EC2 instanstype: m1.small Variasjoner innen hver klokketime: Test: Resultat: Test: Resultat: kl. 12:00 00:03: kl. 18:00 00:03: kl. 13:00 00:03: kl. 19:00 00:03: kl. 14:00 00:03: kl. 20:00 00:03: kl. 15:00 00:03: kl. 21:00 00:03: kl. 16:00 00:03: kl. 22:00 00:03: kl. 17:00 00:03: kl. 23:00 00:03:39 140

141 Illustrasjon av resultatene til test 2 (2.1 og 2.2): Testing av EU 12 timer (12:00 0:00). Figuren viser at 4 slavenoder er dobbelt så rask som 2 slavenoder: Sammenligning av grafikkprosesseringsitid på 2 og 4 slavenoder - Sone EU Tid 00:08:38 00:07:12 00:05:46 00:04:19 00:02:53 2 slavenoder 4 slavenoder 00:01:26 00:00:00 Klokkeslett. Dersom man sammenligner de reelle tallene med de gjennomsnittlige tallene DrQueue oppgir som grafikkprosesseringstid, ser vi at DrQueue konsekvent oppgir bedre tall enn faktisk resultat: Tid 00:08:38 Sammenligning av reelle grafikkprosesseringstider med DrQueue sine gjennomsnittsresultater, Sone EU 00:07:12 00:05:46 00:04:19 00:02:53 2 slavenoder Gj.snitt DrQ - 2 slavenoder 4 Slavenoder Gj.snitt DrQ - 4 slavenoder 00:01:26 00:00:00 Klokkeslett 141

142 Testresultater (rådata) til test 2.1 Amazone Antall Antall Submission Kontroll av Frames Dag Tidspunkt EC2 Fil frames Img.template slaver time Finish time Totaltid Gj. frame tid sn.tid failed: 21.apr 12:00 EU West driven_hand.blend 60 m1.small 2 12:05:03 12:11:49 00:06:46 00:00:13 00:06: apr 13:00 EU West driven_hand.blend 60 m1.small 2 13:05:54 13:12:20 00:06:26 00:00:12 00:06: apr 14:00 EU West driven_hand.blend 60 m1.small 2 14:02:24 14:08:42 00:06:18 00:00:12 00:06: apr 15:00 EU West driven_hand.blend 60 m1.small 2 15:04:11 15:10:31 00:06:20 00:00:12 00:06: apr 16:00 EU West driven_hand.blend 60 m1.small 2 16:06:30 16:14:04 00:07:34 00:00:14 00:07: apr 17:00 EU West driven_hand.blend 60 m1.small 2 17:01:56 17:08:16 00:06:20 00:00:12 00:06: apr 18:00 EU West driven_hand.blend 60 m1.small 2 18:36:37 18:42:56 00:06:19 00:00:12 00:06: apr 19:00 EU West driven_hand.blend 60 m1.small 2 19:13:43 19:20:04 00:06:21 00:00:12 00:06: apr 20:00 EU West driven_hand.blend 60 m1.small 2 20:05:04 20:11:38 00:06:34 00:00:12 00:06: apr 21:00 EU West driven_hand.blend 60 m1.small 2 21:05:47 21:12:28 00:06:41 00:00:13 00:06: apr 22:00 EU West driven_hand.blend 60 m1.small 2 22:00:09 22:06:33 00:06:24 00:00:12 00:06: apr 23:00 EU West driven_hand.blend 60 m1.small 2 23:00:36 23:07:03 00:06:27 00:00:12 00:06:00 0 Testresultater (rådata) til test 2.2 Amazone Antall Antall Submission Kontroll av Frames Dag Tidspunkt EC2 Fil frames Img.template slaver time Finish time Totaltid Gj. frame tid sn.tid failed: 21.apr 12:00 EU West driven_hand.blend 60 m1.small 4 12:19:59 12:23:21 00:03:22 00:00:12 00:03: apr 13:00 EU West driven_hand.blend 60 m1.small 4 13:19:11 13:22:28 00:03:17 00:00:12 00:03: apr 14:00 EU West driven_hand.blend 60 m1.small 4 14:16:09 14:19:28 00:03:19 00:00:12 00:03: apr 15:00 EU West driven_hand.blend 60 m1.small 4 15:20:19 15:23:40 00:03:21 00:00:12 00:03: apr 16:00 EU West driven_hand.blend 60 m1.small 4 16:22:02 16:25:14 00:03:12 00:00:12 00:03: apr 17:00 EU West driven_hand.blend 60 m1.small 4 17:26:15 17:29:35 00:03:20 00:00:12 00:03: apr 18:00 EU West driven_hand.blend 60 m1.small 4 18:47:16 18:50:39 00:03:23 00:00:12 00:03: apr 19:00 EU West driven_hand.blend 60 m1.small 4 19:27:43 19:31:01 00:03:18 00:00:12 00:03: apr 20:00 EU West driven_hand.blend 60 m1.small 4 20:08:04 20:11:31 00:03:27 00:00:13 00:03: apr 21:00 EU West driven_hand.blend 60 m1.small 4 21:23:26 21:26:59 00:03:33 00:00:13 00:03: apr 22:00 EU West driven_hand.blend 60 m1.small 4 22:13:42 22:17:04 00:03:22 00:00:13 00:03: apr 23:00 EU West driven_hand.blend 60 m1.small 4 23:12:25 23:16:04 00:03:39 00:00:14 00:03:

143 3. Måle tiden det tar å bygge, starte og pinge et prosjekt på sky 3.1 Måle tiden det tar å bygge, starte og pinge et renderfarmprosjekt på nettsky Test utført: april, 12:00 12:00 Total varighet: 24 timer Amazon EC2 Sone US East Antall slavenoder: EC2 instanstype: m1.small 2 Variasjoner innen hver klokketime oppgitt i antall sekunder: Test: Tid brukt på å Tid brukt før Test: Tid brukt på å Tid brukt bygge: noden kan bygge: før noden pinge: kan pinge: kl. 14: kl. 2: kl. 15: kl. 3: kl. 16: kl. 4: kl. 17: kl. 5: kl. 18: kl. 6: kl. 19: kl. 7: kl. 20: kl. 8: kl. 21: kl. 9: kl. 22: kl. 10: kl. 23: kl. 11: kl. 0: kl. 12: kl. 1: kl. 13:

144 Illustrasjon av resultatene til test 3.1: Testen er gjort hver klokketime, og viser to grafer, en for bygging av renderfarmprosjekt og en for tiden det tar før noden kan pinge. Sekunder 2500 Sekunder brukt på å bygge et renderfarmprosjekt Sekunder brukt på å bygge 0 Klokkeslett Sekunder Sekunder brukt før noden kan pinge Sekunder brukt før noden kan pinge Klokkeslett 144

145 3.2 Måle tiden det tar å bygge, starte og pinge et renderfarmprosjekt på nettsky over 48 timer Test utført: april, 16:00 Total varighet: 48 timer 16:00 Amazon EC2 Sone US East Antall slavenoder: 2 EC2 instanstype: m1.small Variasjoner i løpet av 48 timer (hver fjerde time), oppgitt i antall sekunder: Test: Tid brukt på å Tid brukt før Test: Tid brukt på å Tid brukt bygge: noden kan bygge: før noden pinge: kan pinge: kl. 16: kl. 20: kl. 20: kl. 00: kl. 00: kl. 04: kl. 04: kl. 08: kl. 08: kl. 12: kl. 12: kl. 16:00 15: kl. 16:

146 Illustrasjon av resultatene til test 3.2: Testen er gjort hver fjerde time i løpet av 48 timer, og viser både tidsbruk på bygging av renderfarmprosjekt og tiden det tar før nodene kan pinge: Sekunder Måling av hvor lang tid det tar å bygge et renderfarmprosjekt, og hvor lang tid det tar før nodene kan pinge :00 20:00 00:00 04:00 08:00 12:00 16:00 20:00 00:00 04:00 08:00 12:00 16:00 20.apr 20.apr 21.apr 21.apr 21.apr 21.apr 21.apr 21.apr 22.apr 22.apr 22.apr 22.apr 22.apr Sekunder brukt på å bygge Sekunder brukt før nodene kan pinge 146

147 3.3 Måle byggetiden parallelt mot Sone US og Sone EU Test utført: april, 12:00 Total varighet: 2 x 24 timer 12:00 Amazon EC2: Sone US Eeast og Sone EU Antall slavenoder: 2 EC2 instanstype: m1.small Variasjoner innen hver klokketime oppgitt i antall sekunder: Test: Sone US Sone EU Test: Sone US Sone EU apr. kl. 20: apr. kl. 04: apr. kl. 00: apr. kl. 08: apr. kl. 04: apr. kl. 12: apr. kl. 08: apr. kl. 16: apr. kl. 12: apr. kl. 20: apr. kl. 16: apr. kl. 00: apr. kl. 20: apr. kl. 04: apr. kl. 08:

148 Illustrasjon av resultatene til test 3.3: Illustrasjonene viser resultatet av sammenligningstesten gjort i forhold til sone US og sone EU. Grafene viser at sone EU generelt ligger lavere i tidsbruk i forhold til US, samt at EU holder et langt jevnere resultat enn US som svinger en del. Testene er gjort i løpet to ulike døgn i løpet av en uke. Der målingene er gjort hver fjerde time. Sekunder Sekunder brukt på å bygge et renderfarmprosjekt, Sone US og Sone EU :00 00:00 04:00 08:00 12:00 16:00 20:00 tor. 22. aprfre. 23. aprfre. 23. aprfre. 23. aprfre. 23. aprfre. 23. aprfre. 23. apr Sone USA Sone EU Sekunder 1600 Sekunder brukt på å bygge et renderfarmprosjekt, Sone US og Sone EU Sone USA Sone EU :00 08:00 12:00 16:00 20:00 00:00 04:00 08:00 søn. 25. apr søn. 25. apr søn. 25. apr søn. 25. apr søn. 25. apr man. 26. apr man. 26. apr man. 26. apr 148

149 4. Måle tiden på grafikkprosessering av stor fil med ulike antall slavenoder, Sone US, instanstype c1.xlarge, og måling av bildetap Test utført: 26. april EC2 instanstype: c1.xlarge Amazon EC2 Sone US East Antall slavenoder: 2, 4, 8 og 16 Grafikkprosesseringsfil: driven_hand.blend Bilder (frames): Test 4XL - Måle tiden og bildetap på grafikkprosesseringsoppgave, 2 slavenoder Test: Resultat: Bildetap: Test: Resultat: Bildetap: XL nr 1 00:15: XL nr 3 00:15: XL nr 2 00:15: XL nr 4 00:15: Test 4XL - Måle tiden og bildetap på grafikkprosesseringsoppgave, 4 slavenoder Test: Resultat: Bildetap: Test: Resultat: Bildetap: XL nr 1 00:07: XL nr 3 00:07: XL nr 2 00:07: XL nr 4 00:07: Test 8XL - Måle tiden og bildetap på grafikkprosesseringsoppgave, 8 slavenoder Test: Resultat: Bildetap: Test: Resultat: Bildetap: XL nr 1 00:04: XL nr 3 00:04: XL nr 2 00:04: XL nr 4 00:04: Test 16XL - Måle tiden og bildetap på grafikkprosesseringsoppgave, 16 slavenoder Test: Resultat: Bildetap: Test: Resultat: Bildetap: XL nr 1 00:03: XL nr 3 00:03: XL nr 2 00:02: XL nr 4 00:03:

150 Illustrasjon av resultatene til test 4: Illustrasjonen viser at det generelt er lite variasjoner på tidsbruk i forhold til de fire testrundene. Ved grafikkprosessering med bruk av 4 slavenoder, var det ingen bildetap. Tidsbruken holdt seg konstant på i underkant av 8 minutt. Tid 00:17:17 Tiden det tar å grafikkprosessere en fil med 3000 bilder 00:14:24 00:11:31 00:08:38 00:05:46 2 slavenoder 4 slavenoder 8 slavenoder 16 slavenoder 00:02:53 00:00:00 Test 1 Test 2 Test 3 Test 4 Testomgang Bildetap ved grafikkprosessering av fil med 3000 bilder Bildetap slavenoder 8 slavenoder 4 slavenoder Test 1 Test 2 Test 3 Test 4 2 slavenoder 150

151 Testresultater (rådata) til test 4 Dag Amazone EC2 Fil Antall frames Img.template Antall slaver Test nr Submission time Finish time Totaltid Frames failed: 26.apr USA East driven_hand.blend 3000 c1.xlarge :25:27 20:33:17 00:07: apr USA East driven_hand.blend 3000 c1.xlarge :36:48 20:44:38 00:07: apr USA East driven_hand.blend 3000 c1.xlarge :47:41 20:55:29 00:07: apr USA East driven_hand.blend 3000 c1.xlarge :57:53 21:05:40 00:07: apr USA East driven_hand.blend 3000 c1.xlarge :46:32 19:51:03 00:04: apr USA East driven_hand.blend 3000 c1.xlarge :54:16 19:59:04 00:04: apr USA East driven_hand.blend 3000 c1.xlarge :03:04 20:07:15 00:04: apr USA East driven_hand.blend 3000 c1.xlarge :10:36 20:14:46 00:04: apr USA East driven_hand.blend 3000 c1.xlarge :52:02 16:55:15 00:03: apr USA East driven_hand.blend 3000 c1.xlarge :00:16 17:03:15 00:02: apr USA East driven_hand.blend 3000 c1.xlarge :05:56 17:09:06 00:03: apr USA East driven_hand.blend 3000 c1.xlarge :11:04 17:14:16 00:03:

152 5. Måle nedlastningstid av en iso-fil fra node på nettsky, til server Test utført: april Total varighet: Hver tredje time i 24 timer Amazon EC2 Sone US East Antall slavenoder: 1 Grafikkprosesseringsfil: minstorefil.iso Filstørrelse: 2048 MB EC2 instanstype: m1.small Variasjoner innen en 12-timers periode: Test: Resultat (sekund): Test: Resultat (sekund): kl. 01: kl. 13: kl. 03: kl. 15: kl. 05: kl. 17: kl. 07: kl. 19: kl. 09: kl. 21: kl. 11: kl. 23:

153 Illustrasjon av resultatene til test 5: Illustrasjonen viser nedlastningstid i sekunder av nedlastning gjort hver tredje time i løpet av et døgn. Grafen nedenfor viser at hver nedlastningstest fikk resultater innenfor 3100 til 3450 sekunder : Sekunder Antall sekunder det tar å laste ned en ISO-fil ved bruk av SCP :00 03:00 05:00 07:00 09:00 11:00 13:00 15:00 17:00 19:00 21:00 23:00 Tid Tidsbruk i sekunder Selv om nedlastningstiden varierer noe, er variasjonene så minimale, at vi kan konkludere med at det ikke er noen nevneverdige variasjoner: Sekunder Antall sekunder det tar å laste ned en ISO-fil ved bruk av SCP 01:00 03:00 05:00 07:00 09:00 11:00 13:00 15:00 17:00 19:00 21:00 23:00 Tid Tidsbruk i sekunder 153

154 00:05 00:15 00:25 00:35 00:45 00:55 01:05 01:15 01:25 01:35 01:45 01:55 02:05 02:15 02:25 02:35 02:45 02:55 03:05 03:15 03:25 03:35 03:45 03:55 04:05 04:15 04:25 04:35 04:45 04:55 00:05 00:20 00:35 00:50 01:05 01:20 01:35 01:50 02:05 02:20 02:35 02:50 03:05 03:20 03:35 03:50 04:05 04:20 04:35 04:50 05:05 05:20 05:35 05:50 06:05 06:20 06:35 06:50 07:05 07:20 07:35 07:50 00:05 00:35 01:05 01:35 02:05 02:35 03:05 03:35 04:05 04:35 05:05 05:35 06:05 06:35 07:05 07:35 08:05 08:35 09:05 09:35 10:05 10:35 11:05 11:35 12:05 12:35 13:05 13:35 14:05 14:35 15:05 6. Måling av trafikkmengde Det er tatt ut datatrafikk på både Dr Queue og NFS. Målingene ble gjort samtidig med test 4. Det er tatt ut data for 4 testomganger på hver av prosjektstørrelsene (2, 4, 8 og 16 slavenoder). Dr Queue Pakker (2, 4, 8, og 16 slavenoder) XL, DrQueue - Pakker XL, DrQueue - Pakker XL, DrQueue - Pakker XL, DrQueue - Pakker 154

155 00:05 00:15 00:25 00:35 00:45 00:55 01:05 01:15 01:25 01:35 01:45 01:55 02:05 02:15 02:25 02:35 02:45 02:55 03:05 03:15 03:25 03:35 03:45 03:55 04:05 04:15 04:25 04:35 04:45 04:55 00:05 00:25 00:45 01:05 01:25 01:45 02:05 02:25 02:45 03:05 03:25 03:45 04:05 04:25 04:45 05:05 05:25 05:45 06:05 06:25 06:45 07:05 07:25 07:45 00:05 00:35 01:05 01:35 02:05 02:35 03:05 03:35 04:05 04:35 05:05 05:35 06:05 06:35 07:05 07:35 08:05 08:35 09:05 09:35 10:05 10:35 11:05 11:35 12:05 12:35 13:05 13:35 14:05 14:35 15:05 Dr Queue Bytes (4, 8, og 16 slavenoder) XL, DrQueue - Bytes XL, DrQueue - Bytes XL, DrQueue - Bytes XL, DrQueue - Bytes 155

156 00:05 00:15 00:25 00:35 00:45 00:55 01:05 01:15 01:25 01:35 01:45 01:55 02:05 02:15 02:25 02:35 02:45 02:55 03:05 03:15 03:25 03:35 03:45 03:55 04:05 04:15 04:25 04:35 04:45 04:55 00:05 00:20 00:35 00:50 01:05 01:20 01:35 01:50 02:05 02:20 02:35 02:50 03:05 03:20 03:35 03:50 04:05 04:20 04:35 04:50 05:05 05:20 05:35 05:50 06:05 06:20 06:35 06:50 07:05 07:20 07:35 07:50 00:05 00:35 01:05 01:35 02:05 02:35 03:05 03:35 04:05 04:35 05:05 05:35 06:05 06:35 07:05 07:35 08:05 08:35 09:05 09:35 10:05 10:35 11:05 11:35 12:05 12:35 13:05 13:35 14:05 14:35 15:05 NFS Pakker (4, 8, og 16 slavenoder) XL, NFS - Pakker XL, NFS - Pakker XL, NFS - Pakker XL, NFS - Pakker 156

157 00:10 00:20 00:30 00:40 00:50 01:00 01:10 01:20 01:30 01:40 01:50 02:00 02:10 02:20 02:30 02:40 02:50 03:00 03:10 03:20 03:30 03:40 03:50 04:00 04:10 04:20 04:30 04:40 04:50 00:05 00:25 00:45 01:05 01:25 01:45 02:05 02:25 02:45 03:05 03:25 03:45 04:05 04:25 04:45 05:05 05:25 05:45 06:05 06:25 06:45 07:05 07:25 07:45 00:05 00:35 01:05 01:35 02:05 02:35 03:05 03:35 04:05 04:35 05:05 05:35 06:05 06:35 07:05 07:35 08:05 08:35 09:05 09:35 10:05 10:35 11:05 11:35 12:05 12:35 13:05 13:35 14:05 14:35 15:05 NFS Bytes (4, 8, og 16 slavenoder) XL, NFS - Bytes XL, NFS - Bytes XL, NFS - Bytes XL, NFS - Bytes 157

158 7. Tiden det tar å starte et renderfarmprosjekt lokalt til alle noder er oppe på Amazon EC2 Test utført: 27. april EC2 instanstype: c1.xlarge Amazon EC2 US East Antall slavenoder: 2, 4, 8 og Test 2XL - Måle tiden fra oppstart av renderfarmprosjekt til alle noder vises som oppe på Amazons kontrollpanel, 2 slavenoder Test: Resultat: Test: Resultat: test nr 1: 2XL 00:01: test nr 3: 2XL 00:01: test nr 2: 2XL 00:01: Test 4XL - Måle tiden fra oppstart av renderfarmprosjekt til alle noder vises som oppe på Amazons kontrollpanel, 4 slavenoder Test: Resultat: Test: Resultat: test nr 1: 4XL 00:07: test nr 3: 4XL 00:07: test nr 2: 4XL 00:07: Test 8XL - Måle tiden fra oppstart av renderfarmprosjekt til alle noder vises som oppe på Amazons kontrollpanel, 8 slavenoder Test: Resultat: Test: Resultat: test nr 1: 8XL 00:01: test nr 3: 8XL 00:01: test nr 2: 8XL 00:01: Test 16XL - Måle tiden fra oppstart av renderfarmprosjekt til alle noder vises som oppe på Amazons kontrollpanel, 16 slavenoder Test: Resultat: Test: Resultat: test nr 1: 16XL 00:03: test nr 3: 16XL 00:02: test nr 2: 16XL 00:02:44 158

159 Illustrasjon av resultatene til test 8: Tid Tiden det tar fra MLN start til alle nodene er oppe, sammenligning av ulike renderfarmprosjekt med ulikt antall slavenoder 00:03:36 00:02:53 00:02:10 00:01:26 2XL (3 noder) 4XL (5 noder) 8XL (9 noder) 16XL (17 noder) 00:00:43 00:00:00 Test 1 Test 2 Test 3 Testrunder Tid Gjennomsnittstid før alle noder er oppe 00:03:36 00:02:53 00:02:10 00:01:26 Gjennomsnittstid 00:00:43 00:00:00 3 noder (2XL) 5 noder (4XL) 9 noder (8XL) 17 noder (16XL) antall noder Kommentar: På prosjekt 2XL, 4XL og 8XL ser det ut til at den siste noden ofte henger ca 10 sekunder etter. Når man skal blåse opp 16XL, så ser det ut til at Amazon tar for seg 9-10 noder av gangen og først setter i gang med de 7-8 siste når disse er helt oppe. Dvs de står ikke engang som pending får de ti første viser grønt. Amazon kan tydeligvis kun allokere minne til 10 noder av gangen. 159

160 8. Måle tiden det tar å grafikkprosessere en stor fil lokalt med en slave Test utført: 27. april Antall slavenoder: 1 Grafikkprosesseringsfil: driven_hand.blend Bilder: 3000 Total grafikkprosesseringstid: 00:35:35 Bildetap: 0 Printscreen av informasjonsbildet i DrQman: 160

161 9. Undersøkelser knyttet til kostnader Priser tilsvarende prosjekt med 2 slavenoder: Pris og Antall 2U-rakkenhet antall 3 R510 Chassis, Up to 8x3.5" Hot-Plug HDs Intel 55xx Support, LCD Diags Supports Hot Swap PSUs Rabatt (opp til kr) Pris x antall - rabatt Konsoll Svitsj PowerEdge 2160AS Analogue 16 Port KVM Switch Rakk-skap U Rack, 5x Rack Power Cord 220V (Kit) Set of 4 Fans for 42U Rack Model 4210 (Kit) Total NOK inklusiv frakt og moms

162 Priser tilsvarende prosjekt med 4 slavenoder: Pris og Antall 2U-rakkenhet antall 5 R510 Chassis, Up to 8x3.5" Hot-Plug HDs Intel 55xx Support, LCD Diags Supports Hot Swap PSUs Rabatt (opp til kr) Pris x antall - rabatt Konsoll Svitsj PowerEdge 2160AS Analogue 16 Port KVM Switch Rakk-skap U Rack, 5x Rack Power Cord 220V (Kit) Set of 4 Fans for 42U Rack Model 4210 (Kit) Total NOK inklusiv frakt og moms

163 Priser tilsvarende prosjekt med 6 slavenoder: Pris og Antall 2U-rakkenhet antall 7 R510 Chassis, Up to 8x3.5" Hot-Plug HDs Intel 55xx Support, LCD Diags Supports Hot Swap PSUs Rabatt (opp til kr) Pris x antall - rabatt Konsoll Svitsj PowerEdge 2160AS Analogue 16 Port KVM Switch Rakk-skap U Rack, 5x Rack Power Cord 220V (Kit) Set of 4 Fans for 42U Rack Model 4210 (Kit) Total NOK inklusiv frakt og moms

164 Priser tilsvarende prosjekt med 8 slavenoder: Pris og Antall 2U-rakkenhet antall 9 R510 Chassis, Up to 8x3.5" Hot-Plug HDs Intel 55xx Support, LCD Diags Supports Hot Swap PSUs Rabatt (opp til kr) Pris x antall - rabatt Konsoll Svitsj PowerEdge 2160AS Analogue 16 Port KVM Switch Rakk-skap U Rack, 5x Rack Power Cord 220V (Kit) Set of 4 Fans for 42U Rack Model 4210 (Kit) Total NOK inklusiv frakt og moms

165 Priser tilsvarende prosjekt med 10 slavenoder: Pris og Antall 2U-rakkenhet antall 11 R510 Chassis, Up to 8x3.5" Hot-Plug HDs Intel 55xx Support, LCD Diags Supports Hot Swap PSUs Rabatt (opp til kr) Pris x antall - rabatt Konsoll Svitsj PowerEdge 2160AS Analogue 16 Port KVM Switch Rakk-skap U Rack, 5x Rack Power Cord 220V (Kit) Set of 4 Fans for 42U Rack Model 4210 (Kit) Total NOK inklusiv frakt og moms

166 Priser tilsvarende prosjekt med 16 slavenoder: Pris og Antall 2U-rakkenhet antall 17 R510 Chassis, Up to 8x3.5" Hot-Plug HDs Intel 55xx Support, LCD Diags Supports Hot Swap PSUs Rabatt (opp til kr) Pris x antall - rabatt Konsoll Svitsj PowerEdge 2160AS Analogue 16 Port KVM Switch Rakk-skap U Rack, 5x Rack Power Cord 220V (Kit) Set of 4 Fans for 42U Rack Model 4210 (Kit) Total NOK inklusiv frakt og moms

167 Strømforbruk Strømførbruket er i samsvar med antall rakkenheter der hver rakkenhet krever 300W. Oppsettet under viser en server med 3 rakkenheter. Ved større servere med flere rakkenheter vil strømforbruket øke med 300W per rakkenhet. Rakkenhet (3 enheter x 300W) 900W Per enhet: Prosessorer 2x80W Nettverkskort Hardisk 4x8W CD rom enhet Hovedkort Vifter Ram 8x2W Konsoll Svitsj 160W 10W 32W 8W 20W 24W 16W 30W Rakkskap (1 enhet x 200W) 200W Per enhet: Vifter 200W Totale Watt forbruk 1100W 167

168 Vedlegg 5 Tilleggstester Dag Sone Fil Antall bilder Instansty pe Slaver Start Slutt Totaltid Bildeta p 09.mai USA East driven_hand.blend 3000 c1.xlarge 1 10:55:51 11:25:51 00:30: mai USA East driven_hand.blend 3000 c1.xlarge 1 11:47:51 12:17:54 00:30: mai USA East driven_hand.blend 3000 c1.xlarge 1 12:26:18 12:56:28 00:30: mai USA East driven_hand.blend 3000 c1.xlarge 1 13:02:46 13:32:53 00:30: mai USA East driven_hand.blend 3000 c1.xlarge 1 13:34:56 14:05:08 00:30:12 0 Gjennomsnitt 00:30:06 11.mai USA East driven_hand.blend 3000 c1.xlarge 2 15:09:56 15:26:10 00:16: mai USA East driven_hand.blend 3000 c1.xlarge 2 15:28:16 15:44:32 00:16: mai USA East driven_hand.blend 3000 c1.xlarge 2 15:50:19 16:06:35 00:16: mai USA East driven_hand.blend 3000 c1.xlarge 2 16:11:19 16:27:28 00:16: mai USA East driven_hand.blend 3000 c1.xlarge 2 16:30:32 16:46:52 00:16:20 0 Gjennomsnitt 00:16:15 12.mai USA East driven_hand.blend 3000 c1.xlarge 4 04:46:51 04:54:52 00:08: mai USA East driven_hand.blend 3000 c1.xlarge 4 04:58:30 05:06:22 00:07: mai USA East driven_hand.blend 3000 c1.xlarge 4 05:08:15 05:16:03 00:07: mai USA East driven_hand.blend 3000 c1.xlarge 4 05:18:44 05:26:35 00:07: mai USA East driven_hand.blend 3000 c1.xlarge 4 05:27:38 05:35:26 00:07: mai USA East driven_hand.blend 3000 c1.xlarge 4 05:38:54 05:46:48 00:07:54 0 Gjennomsnitt 00:07:52 13.mai USA East driven_hand.blend 3000 c1.xlarge 6 20:34:32 20:39:54 00:05: mai USA East driven_hand.blend 3000 c1.xlarge 6 23:13:53 23:19:13 00:05: mai USA East driven_hand.blend 3000 c1.xlarge 6 23:24:25 23:29:44 00:05: mai USA East driven_hand.blend 3000 c1.xlarge 6 23:34:47 23:40:05 00:05: mai USA East driven_hand.blend 3000 c1.xlarge 6 23:45:24 23:50:46 00:05: mai USA East driven_hand.blend 3000 c1.xlarge 6 23:54:06 23:59:28 00:05: mai USA East driven_hand.blend 3000 c1.xlarge 6 00:00:33 00:05:49 00:05: mai USA East driven_hand.blend 3001 c1.xlarge 6 00:13:40 00:19:02 00:05:22 0 Gjennomsnitt 00:05:20 12.mai USA East driven_hand.blend 3000 c1.xlarge 8 05:58:11 06:02:14 00:04: mai USA East driven_hand.blend 3000 c1.xlarge 8 06:04:08 06:08:28 00:04: mai USA East driven_hand.blend 3000 c1.xlarge 8 06:13:19 06:20:56 00:07: mai USA East driven_hand.blend 3000 c1.xlarge 8 06:23:46 06:28:07 00:04: mai USA East driven_hand.blend 3000 c1.xlarge 8 06:30:58 06:35:28 00:04: mai USA East driven_hand.blend 3000 c1.xlarge 8 06:36:59 06:40:59 00:04:00 0 Gjennomsnitt 00:04:49 09.mai USA East driven_hand.blend 3000 c1.xlarge 10 14:33:57 14:37:34 00:03: mai USA East driven_hand.blend 3000 c1.xlarge 10 14:53:36 14:57:15 00:03: mai USA East driven_hand.blend 3000 c1.xlarge 10 14:59:32 15:03:26 00:03: mai USA East driven_hand.blend 3000 c1.xlarge 10 15:06:22 15:10:17 00:03: mai USA East driven_hand.blend 3000 c1.xlarge 10 15:13:01 15:16:49 00:03:48 10 Gjennomsnitt 00:03:47 168

169 Vedlegg 6 Brukermanual for Ymer Denne brukermanualen forutsetter at du har en server med Xen Hypervisor, og MLN installert. Innhold AMI og Amazon EC2 DynDNS MLN-konfigurasjonsfil Bygging og oppstart av Ymer AMI og Amazon EC2 For å kunne benytte deg av Amazones tjenester, må du registrere deg som bruker. Dette kan du gjøre her: For å bygge filsystemene for nodene, kan du laste ned et AMI fra Amazones EC2s hjemmeside. Dette kan gjøres ved å følge denne lenken: 169

170 Alternativt, så kan du laste ned filsystemene vi har brukt, så slipper du installere all programvaren i et nytt AMI selv. Når du laster ned filsystemet, legger du det i mappen som heter /opt/mln/templates: $ wget $ wget DynDNS For at det skal være mulig for MLN å spore mesternodens IP-adresse på Amazone EC2, må du registrere deg som bruker hos DynDNS.com. Dette er en tjeneste som er gratis, og man kan også kostnadsfritt registrere IP-adresser med et alias hos DynDNS. DynDNS har en god forklaring på hvordan man går frem for å gjøre dette her: 170

171 MLN-konfigurasjonsfil Nå er filsystemene for nodene klare, og du kan hente en av MLN-filene vi har brukt til bygging av Ymer, på vår hjemmeside: Om du ønsker å lage din egen MLN-fil, kan du også det. Du finner mer informasjon om MLN på hjemmesiden: Etter at du har hentet MLN-filen du ønsker å benytte deg av, må du huske på å tilpasse den noe. Filsystemene for de to nodetypene må legges inn i konfigurasjonsfilen, som vist i eksempelet under. Du må også legge inn DynDNS alias for mesternoden, samt brukernavn og passord til din DynDNSbruker i dyndns-blokken. 171