Hovedopgave Master i Informationsteknologi linien i Softwarekonstruktion

Transkript

1 DATALOGISK INSTITUT DET NATURVIDENSKABELIGE FAKULTET AARHUS UNIVERSITET Hovedopgave Master i Informationsteknologi linien i Softwarekonstruktion Evaluering af Udbud og Modenhed af Cloud Computing Software Teknologier af Thomas Mollerup Lanng {u070583@cs.au.dk, thomas.lanng@gmail.com} Thomas Mollerup Lanng, studerende Henrik Bærbak Christensen, vejleder Datalogisk Institut Aarhus Universitet Åbogade Århus N Tlf.: Fax: cs@cs.au.dk

2 Indholdsfortegnelse 1 Indledning Motivation Problemformulering Planlægning Udviklingsmetode Plan Konfiguration Teori Arkitektur beskrivelse Autonomic computing Cloud computing Kvalitetsattribut scenarier Metode Projektfaser Foranalyse Eksperiment Og Evaluering Kvalitetsattribut Scenarier Usability scenarie 1: Opsætning af udviklingsmiljø Usability scenarie 2: Udvikling af første services Usability scenarie 3: Tilvejebringelse af instanser Usability scenarie 4: Overvågning og SLA Evalueringstaksonomi Analyse Og Resultater Foranalyse Kandidater Evaluering Microsoft Azure Amazon EC Google App Engine Heroku Joyent Konklusion Eksperiment Case beskrivelse Evaluering Usability scenarie 1: Opsætning af udviklingsmiljø Usability scenarie 2: Udvikling af første services Usability scenarie 3: Tilvejebringelse af instanser Usability scenarie 4: Overvågning og SLA Konklusion Konklusion Referencer Tidsplan Appendiks: EC2 fejl fundet ved test Side 2 af 159

3 1 INDLEDNING Denne rapport behandler konceptet autonomic computing med hensyn til cloud computing teknologier og disses modenhed i forhold til realisering af den self managed autonome arkitektur [3, 4]. Denne rapport komplementerer tidligere arbejde i rapporten Evaluering af udbud og modenhed af self managed arkitektur software teknologier [12] ved at fokusere på, hvorledes eksisterede cloud computing teknologier understøtter autonom computing. Desuden er samme faseopdelte metode anvendt i evalueringen af teknologierne. Der er valgt at evaluere et udsnit af relevante teknologier ved en kvalitativ og kvantitativ tilgang. Hermed kan resultater både verificeres og valideres i de relevante miljøer. Dette gøres ved en evaluering af teknologiernes egenskaber ud fra en gennemgang af kriterier og en eksperimentel del, hvor brugbarheds kvalitetsattribut scenarier anvendes i evalueringen. Arbejdsprodukterne for denne rapport er : - en sammenligning af cloud computing og self managed arkitekturer, - et survey af relevante cloud computing teknologier, - evaluering af disse i forhold til self managed autonom arkitektur, - en evalueringsmetode, - en taksonomi som kan anvendes til evaluering af cloud computing teknologier og - udvikling af prototype autonomt system ved hjælp af en udvalgt cloud computing teknologi. Rapporten behandler emnet i en struktur af 7 afsnit. Afsnit 1, dette afsnit, beskriver emnet som behandles herunder anvendt metode og arbejdsprodukter. Afsnit 2 beskriver min motivation for udarbejdelse af denne rapport. Afsnit 3 beskriver problemformuleringen for rapporten. Afsnit 4 beskriver planlægning af projektet herunder valg af udviklings metode, tidsplan og konfiguration. Afsnit 5 indeholder en beskrivelse af teori for emnet. Afsnit 6 beskriver metoden anvendt i rapporten til behandling af emnet. Afsnit 7 indeholder en analyse af problemet sammen med resultater. Analysen følger metoden valgt, som beskriver faserne: foranalyse, eksperiment og evaluering. For-analysen lister bruttolisten af kandidater fra informationssurvey, en evaluering af disse og en udvælgelse af en teknologi til den næste eksperimentelle fase. Den eksperimentelle fase beskriver en case som anvendes til udvikling af et prototype system ved hjælp af den udvalgte teknologi. Herefter foretages en erfaringsopsamling og en endelig evaluering af resultater. Afsnit 8 giver et resume af rapport resultater og en samlet konklusion. Side 3 af 159

4 2 MOTIVATION Jeg finder, at cloud computing er et både aktuelt og spændende emne og har derfor defineret et projekt, hvori der arbejdes videre med emnet i forhold til pensum for tidligere kursus. I projektet arbejdes med udgangspunkt i kursets teoretiske gennemgang af emnet, men der fokuseres desuden på den operationelle teknologi vinkel, det vil sige hvilke cloud computing teknologier eksisterer til understøttelse af konceptet autonomic computing og self managed arkitektur og hvilken modenhed disse har. Det er forventet, at dette arbejde skal bidrage til en kvalificeret diskussion af cloud computing og eksisterende teknologier i forhold til autonom computing herunder eventuelle begrænsninger i en erhvervsmæssig sammenhæng. 3 PROBLEMFORMULERING I denne rapport foretages en evaluering af udbud og modenhed af cloud computing teknologier, der understøtter autonom computing teorien, som defineret af Kephart et. al. [3] og White et. al. [4]. I projektet vil følgende spørgsmål blive besvaret: Hvilke cloud computing teknologier understøtter helt eller dele af teorien? Hvordan er modenheden af de aktuelle cloud computing teknologier? Modenheden af de udvalgte cloud computing teknologier vurderes ud fra en evalueringstaksonomi med følgende kriterier: Hvor godt understøttes autonmic computing teorien? Hvor svært er det at anvende (defineret vha. usability kvalitetsattribut scenarier)? Hvor god er dokumentationen? Hvordan vedligeholdes teknologien? Hvilken værktøjs understøttelse findes? Hvilke standarder understøttes? Side 4 af 159

5 4 PLANLÆGNING I det følgende gennemgås planlægning for projektet. 4.1 UDVIKLINGSMETODE Projektet er udarbejdet af enkelt person, derfor er der ikke fokuseret på vidensdeling og opgavedeling, som ellers ville have været relevant. I stedet er der arbejdet efter metoden beskrevet i rapporten og afsat faste tidsperioder til at arbejde med problemstillingen. Hvor det er muligt anvendes en agile tilgang til udvikling, således, at funktionalitet udvikles iterativt. Dermed er det muligt kontrolleret at teste og indføre ændringer. 4.2 PLAN Planlægningen af rapport projekt arbejde følger faserne for den valgte projekt metode: foranalyse, eksperiment og evaluering. Der er valgt en beskrivelse af opgaver på uge basis, således det er muligt at styre og følge op på opgaverne. Projektet forventes at have den største arbejdsbelastning i informationsindsamling herunder artikler og teknologier, evaluering og realisering. Estimat [uger] Uge nr Opgave 1 35 Synopsis og tidsplan 1 36, 37 Informations indsamling 1 38 Teori udvælgelse og beskrivelse 1 39 Metode beskrivelse 2 40, 41 Udvælgelses af kandidater 2 42, 43 Evaluering af kandidat 2 44, 45 Beskrivelse af kvalitetsscenarier 2 46, 47 Beskrivelse af case 3 48, 49, 50 Realisering af case 1 51 Evaluering af kandidat 2 52, 1 Konklusioner 1 2 Rapport sammenfatning Tabel 1: Planlægning af projekt rapport. 4.3 KONFIGURATION Til styring af opgaver og tid anvendes der et regneark med de nævnte data som overskrifter. Opgave listen findes i bilag Tidsplan. Til dokument og kildekode konfigurationsstyring anvendes Google Code[14] Subversion repository. Side 5 af 159

6 5 TEORI I dette afsnit gennemgås teori relevant for behandlingen problemstillingen. - Arkitektur beskrivelse - Definition af kvalitetsattribut scenarier - Kvalitetsattribut scenarier til beskrivelse af brugbarhed af teknologier - Definition af autonomic computing - principper, self managed arkitektur krav - Definition af cloud computing og taksonomi 5.1 ARKITEKTUR BESKRIVELSE Hovedteorien i denne rapport er baseret på en arkitektur tilgang for at opnå målene for autonomic computing, hvor især viewpoints component & connector behandles. Ontologien for arkitektur beskrivelse ses i Figur 1, hvor der introduceres abstraktioner viewpoint og views til beskrivelse af forskellige perspektiver af en arkitektur til forskellige interessenter (stakeholders). I denne rapport anvendes viewpoints: component & connector, module og deployment. Figur 1: Ontologi af en arkitektur beskrivelse, opgave anvendte views er markeret rødt [10]. De 3 viewpoints beskrives i Tabel 2 [10] med strukturen formål, elementer og relationer. Viewpoint Module viewpoint Formål Beskrivelse Dette viewpoint beskriver, hvorledes funktionalitet overføres til de implementerede enheder (units). Elementer - Klasse: beskriver egenskaberne for objekterne, som eksisterer på runtime tidspunkt. - Pakke(package): beskriver en logisk opdeling af klasser i systemet. Side 6 af 159

7 - Interface: en klassifikation af interfacet, som elementet implementerer. Relationer - Association: beskriver, at det findes et aggregation forhold mellem elementerne og kan anvendes mellem klasser. - Generalization: beskriver, at der findes en generalization relation mellem elementerne og kan anvendes mellem 2 klasser eller 2 interfaces. - Realization: beskriver at, et element realiserer et andet og kan anvendes fra en klasse og til interfacet, som den realiserer - Dependency: beskriver, at der findes en afhængighed mellem elementer og kan anvendes mellem alle elementer. Component & connector viewpoint Formål Dette viewpoint beskriver runtime funktionalitet for systemet. Elementer - Component: et runtime objekt med veldefineret rolle og ansvar. Relationer - Connector: er en kommunikations relation mellem komponenterne, som definerer hvorledes kontrol og data overføres. Deployment viewpoint Formål Dette viewpoint beskriver, hvorledes system elementerne overføres til platform elementer i form af hardware og runtime miljø. Elementer - Software: dette kan være eksekverbare objekter eller software biblioteker (libraries) komponenter fra C&C viewpoint. - Miljø: Hardware computer knuder. Relationer - Allocated-to:beskriver, hvilke miljø komponenter, som software elementer bliver allokeret til på runtime tidspunktet. Dette kan være statiske eller dynamiske relationer, hvis komponenter flyttes mellem miljø komponenter. - Dependencies: Afhængigheder mellem software elementer. - Protokol links: beskriver protokol links mellem miljø elementer og viser kommunikations protokol anvendt mellem knuder. Tabel 2: Beskrivelse af arkitektur viewpoints [10]. 5.2 AUTONOMIC COMPUTING Præmis [2, 3, 4]: Computer systemer bliver stadig mere komplekse og nærmer sig grænsen for, hvad mennesker kan håndterer. For at håndtere dette forslås i stedet autonome computer systemer. Definition og visionær succes mål [2, 3, 4]: Store computer systemer, der styrer sig selv i forhold til højniveau målsætninger fra mennesker. De lever deres eget liv og fungere autonomt i deres miljø. Side 7 af 159

8 Egenskaber[2, 3, 4]: Autonome systemer beskrives ud fra aspekter af selv styring (self-management) også benævnt CHOP (Configuration, Healing, Optimization og Protection), Tabel 1. Aspekt Selvconfiguration Self-healing Self-optimizing Self-protecting Beskrivelse Automatiseret konfiguration af komponenter og system som følger højniveau politikker. Resten af system justerer sig automatisk og problemfrit. Systemet detekterer automatisk, diagnosticerer og reparerer lokaliserede software og hardware problemer. Komponenter og systemer søger kontinuerligt at forbedre deres ydelse og effektivitet. Systemet forsvarer sig automatisk mod ondsindede angreb eller flere på følgende fejl. Det benytter tidlig advarsel og forhindrer fejl på system niveau. Tabel 1: Self management aspekter [3]. Arkitektur tilgang White et al.[4] foreslår en arkitektur baseret tilgang til at opnå de autonome computing succes mål. I denne tilgang er det autonome element eller komponent et centralt koncept, Figur 1. Figur 1: Det autonome element [3]. Det autonome element indeholder en autonom manager, som yderligere er opdelt i funktionalitet til: Monitorering, Analyse, Planlægning, Eksekvering og Viden. Desuden indeholder det autonome element elementet som skal styres af manager. Dette foregår i en kontrol løkke, hvor manager har et sensor interface til elementet, som kontinuerligt monitorers i forhold til politikkerne, der er defineret for elementet. Hvis elementet afviger fra de definerede politikker, detekteret i analyse delen, så foretager manager korrigerende aktiviteter i forhold til beskrivelse i planen og vha. viden. De korrigerende aktiviteter eksekveres på elementet. Dette danner en kontrol løkke. Et autonomt element kan repræsenterer f.eks. en lagringsenhed i et system. Komponenterne i et autonomt system er autonome elementer. Side 8 af 159

9 White et al.[4] stiller krav til et autonomt element, som indgår i en autonom arkitektur indenfor områderne: - Interface - Opførsel for elementet - Etablering af interaktion med andre elementer Kravene indenfor disse områder er blevet uddraget fra [4] og beskrevet i Tabel 2 fra tidligere rapport [12] Evaluering af udbud og modenhed af self managed arkitektur software teknologier. Denne kravs liste anvendes til evalueringen af teknologier som understøtter udvikling af systemer baseret på denne arkitektur. Hovedkategori Underkategori Krav Id Krav beskrivelse Opførsel Element KO.1 Skal være self-managing det vil sige ansvarlig for: - intern konfiguration(self-configuration) - overkomme interne fejl (self-healing) - optimering af opførsel (self-optimizing) - beskytte mod ekstern probing og angreb (self-protecting) KO.2 Skal håndtere problemer lokalt, hvor muligt for at gøre global system management simplere (service afhængighed ikke opfylder aftale - f.eks. kræve den opfyldes eller afslutte relation og finde en anden service udbyder ) Relationer KO.3 Etablere og vedligeholde relationer med andre autonome elementer herunder hvilke services udbydes til og services som benyttes KO.4 Service skal beskrives korrekt og være tilgængelig og forståelig for andre autonome elementer KO.5 Skal forstå og opfylde aftale krav Politikker (policies) KO.6 KO.7 KO.8 KO.9 KO.10 KO.11 KO.12 KO.13 KO.14 KO.15 KO.16 KO.17 Skal kunne forhandle for at etablere aftaler (relationer) Skal kunne styre opførsel og relationer således, at dens forpligtigelser(obligations) opfyldes, dette kan gøres ved konfiguration af egne parametre eller ved at anvende andre autonome elementers resurser 2 typer forpligtigelse(obligations): - opfylde aftaler(agreements) og - modtage og opfylde politikker(policies) Skal forkaste service forespørgsler som bryder politikker eller aftaler Skal nægte eller give andre forslag til foreslåede relationer eller politikker som vil bryde eksisterende relationer eller politikker Administrative relationer håndteres lige som andre relationer Direktiver modtagnes på samme måde som andre forespørgsler; hvis politikken beskriver at forespørgeren har rettighed til at få udført kommando, så udføres denne Konfliktende forespørgsler fra administrative elementer skal løses af det modtagne element Skal kunne oversætte højniveau, globale direktiver til specifikke aktiviteter vha. politikker En politik er en repræsentation i en standard ekstern form for ønskede opførsel eller begrænsninger på opførsel Der tillades mindst 3 niveauer af relaterede politikker: - Action politikker er den laveste politik specifikation, som typisk har en if-then kontrol struktur f.eks. If(ResponseTime > 2 sec) Then (CPU+5%) - Et autonomt element der benytter action politikker skal måle kvantiteterne beskrevet i betingelsen(if) og udføre action (Then), når betingelsen er opfyldt - Mål politikker (goal policies) er det mellemste niveau af politikker, som beskriver betingelser som skal opfyldes, men uden at beskrive hvordan, dette kunne f.eks. være respons tid må ikke overstige 2 sek. - Utility function politikker er det højeste niveau af politikker, som at specificere de relative ønskede alternative tilstande, hvilket opnås ved at tildele en numerisk værdi eller en partiel eller fuldstændig beskrivelse af rækkefølge for mulige tilstande Et autonomt element, der benytter action politikker, skal måle kvantiteterne beskrevet i betingelsen(if) og udføre action (Then), når betingelsen er opfyldt Side 9 af 159

10 KO.18 Et element, der benytter Utility function politikker, skal have tilstrækkelig modellering og optimeringsegenskaber for at oversætte mål til actions Interface Element KI.1 Udover standard interfaces som en serviceorienteret arkitektur beskriver, hvor services beskrives, søges/findes og leveres skal autonome elementer yderligere System sammensætning Monitoring og test interfaces Lifecycle interfaces KI.2 KI.3 KI.4 KI.5 realisere interfaces for at opnå self management Dette gør det muligt for at et element at blive monitoreret af et andet element med de nødvendige rettigheder Kan anvendes til at styre mængden af logning og trace data, som et element indsamler og få tilgang til dette data Kan anvendes til at instruere et element til at udføre en self-test og tilgå resultater Muliggør for administrative elementer at forespørge lifecycle tilstanden af et element f.eks. om det er startet eller i pause og hvilken lifecycle model der anvendes KI.6 Muliggør ændring af lifecycle tilstand for et element f.eks. nedlukning Politik interface KI.7 Muliggør for administrative elementer at sende nye politikker til et element og politikker som anvendes at elementet Negotiation og binding KI.8 Tillader et element at forespørge en service fra et andet element eller at blive forespurgt at levere en service interfaces KI.9 I den simple form, som anvendes i serviceorienteret arkitekturer, tillades et element at forespørge en specifik service og modtage enten en bekræftelse eller en fejl Relationer (relationships) Inteaction integrity KI.10 KI.11 KI.12 KI.13 KI.14 KI.15 KI.16 I den avancerede form som tillader mere fleksibel self-management kan elementer også understøtte interfaces som tillader: forslag eller mod forslag, forhandling om eksakte betingelser og egenskaber for service der skal leveres (herunder reliabilty, availability, performance mv.), og dannelse og styring af langtids relationer Opstår når et element har tilladt at levere en service til et andet element typisk ved forhandling mellem elementerne En forhandling kan fejle som følge af manglende rettigheder eller elementet ikke har tilstrækkelige ressourcer Relationer er måden hvorpå elementer sammensættes til at danne et autonomt system Relationer dannes typisk runtime (modsat fastholdt ved udrulning) og kan ændres på et givent tidspunkt Relationer dannes af elementerne selv og ikke af administratorer Et autonomt element skal kommunikere med andre elementer via service interfaces defineret i den tilknyttede service specifikation og må ikke kommunikere på andre måder KI.17 Et elements interne kommunikation må ikke blive tilgængelig udenfor elementet Interaktion KS.1 For at opnå self management på system niveau skal dets elementer være i stand til at kommunikere og koordinere, således at deres gensidige mål kan opnås. Discovery KS.2 Autonome elementer skal kunne finde/søge andre elementer KS.3 Autonome elementer skal kunne identificere andre elementer for kommunikation Komposition KS.4 Autonome elementer skal via andre elementer kunne opnå end-to-end service level mål Støtte elementer KS.5 For at opnå dette anvendes et antal af infrastruktur elementer: Registry: - Tilbyder mekanismer således elementer kan finde andre elementer og forbinde sig med hinanden - Tilbyder mekanismer således elementer kan publicere services Sentinel: - Tilbyder services til monitorering for andre elementer Aggregator: - Kombinere 2 eller flere elementer, således at en forbedret services kan tilbydes f.eks. højere pålidelighed eller performance end elementer hver for sig er i stand til Broker: - Faciliteter interaktion f.eks. ifm. at støtte et element med at udføre opgaver som kræver komplekse relationer Side 10 af 159

11 - Kan danne en aggregering af elementer, som opfylder specifikt behov f.eks. lagringsservices og give denne adresse til et element Negotiator: - Støtter andre elementer i at fortage komplekse forhandlinger som f.eks. kræver rationale som det enkelte element ikke er i stand til, f.eks. trade off latency ift. Throughput Tabel 2: Krav til self managed arkitektur[12]. Side 11 af 159

12 5.3 CLOUD COMPUTING Der findes mange definitioner af cloud computing [7, 17, 18, 19, 20, 21, 24, 25]. Fælles for definitionerne er et distribueret system, som dynamisk allokere ressourcer vha. virtualiserings teknologi. Buyya [7] definerer cloud computing som: Definition: En cloud er en parallel og distribueret type system bestående af en samling forbundne og virtualiserede computere, som allokeres dynamisk og præsenteres som en computer ressource baseret på service level agreements (SLA) etableret gennem forhandling mellem service udbyder og service brugere. Taksonomi Taksonomien for en cloud computing kan beskrives, som på Figur 2. Figur 2: Cloud arkitektur [19]. Denne taksonomi præsenterer cloud computing, som service lag, hvor der tillægges funktionalitet for at komme op på det næste lag. Service lagene beskrives nedenfor. Side 12 af 159

13 Infrastructure as a Service (IaaS): Dette lag er tættest på hardwaren. Der skelnes mellem 2 typer af services: Physical Resource Set (PRS) og Virtual Resource Set (VRS). Begge service typer udbyder et management API til en ressource pool, som tillader at automatisere setup og tear-down samt skalering. Individuelle ressourcer kan startes og stoppes, operativ systemer kan kopiers (image) og kapacitet kan konfigureres. Platform as a Service (PaaS): Dette lag opdeles i programmeringsmiljø og afviklingsmiljø. Denne opdeling tillader udskiftning af programmeringsmiljø, hvis ønskes. Software as a Service (SaaS): Alle applikationer, som afvikles i cloud med direkte interface til brugeren er placeret i SaaS laget. Der skelnes mellem basic application services og composite application services. Human as a Service (HuaaS): Dette lag er målrettet services, som kræver interaktion med information fra mange mennesker. Hvert menneske kan anvende en given teknologi eller værktøj for at løse opgaven. Udrulning/ deployment Cloud computing kan udrulles på forskellig vis. Figur 3 viser de 4 udrulnings taktikker. Figur 3: Cloud udrulning [23]. Private Denne taktik anvendes, når brugere sætter krav til datasikkerhed, corporate governance eller pålideligheds hensyn. Servere og andet udstyr findes lokalt i virksomheden og skal også vedligeholdes her. Public Denne beskriver cloud computing, som defineret, hvor ressourcer dynamisk allokeres på selvbetjeningsbasis over internettet, via web applikation eller fra 3. parts udbyder. Side 13 af 159

14 Hybrid En hybrid model består af flere interne og eksterne udbydere. Dette giver mulighed for at opfylde specifikke krav og anvende den eksterne udbyder, når dette er optimalt. Intercloud En intercloud er en cloud of clouds, hvor man sammensætter flere clouds for at opnå ønskede egenskaber og præsentere denne som en cloud. I denne rapport vil udrulnings modellen Public cloud anvendes. Side 14 af 159

15 5.4 KVALITETSATTRIBUT SCENARIER I denne rapport anvendes teori fra kvalitetsrammeværk Bass [10], kvalitetsattributter og kvalitetsattribut scenarier. Specifikt anvendes usability (brugbarhed) til at beskrive ønsket kvalitets krav til evaluering af udvalgte teknologi kandidat. Kvalitetsattributter: beskriver en veldefineret egenskab og metrik i det resulterende system. Kvalitetsattributterne er klassificeret i 3 klasser: system, forretning, arkitektur. Disse beskrives i Tabel 3. System Arkitektur Forretning Tilgængelighed (Availability) Konceptuel integritet (Conceptual integrity) Tiden til marked (Time to market) Modificerbarhed Korrekthed og Kost (Cost) (Modifiability) fuldstændighed (Correctness and completeness) Ydelse (Performance) Realiserbarhed (Buildability) Projekteret livstid (Projected lifetime) Sikkerhed (Security) Marked målgruppe (Targeted market) Testbarhed (Testability) Udrulnings tidsplan (Rollout schedule) Brugbarhed (Usability) Integration med legacy systemer (Integration with legacy systems) Tabel 3: Kvalitetsattribut kategori klasser [10]. Kvalitetsattribut scenarier: definerer en metrik, sætter en given kvalitetsattribut i en kontekst og forankrer kvalitetskrav i et specifikt scenarie / brugsmønster. Disse scenarier er baseret på stimulus modellen i Figur 2. Figur 2: Kvalitetsattribut scenario for usability [10]. Elementerne, der indgår i et kvalitetsattribut scenarie, er listet i Tabel 4. Scenarie element Stimulus kilde Beskrivelse Dette er en entitet i form af et menneske eller et computer system eller en anden aktuator som genererede stimulus. Side 15 af 159

16 Stimulus En kondition der skal overvejes, når det ankommer til et system. Miljø Stimulus fremkommer indenfor bestemte konditioner. Dette kunne f.eks. være et system i en overbelastnings kondition. Artefakt Et artefakt stimuleres. Dette kan være hele systemet eller dele af det. Svar Svaret er den aktivitet der foretages på baggrund af ankomsten af stimulus. Svar måleenhed Når svaret på stimulus forekommer skal dette være målbart, således at kravet kan testes. Tabel 4: Kvalitetsattribut scenarie beskrivelse [10]. Et generelt usability scenarie, som anvendt i rapporten, ses i Tabel 5. Usability scenarie er relevant for, hvor nemt det er for en bruger at udføre en ønsket opgave og hvilken bruger understøttelse system tilbyder. Her beskrives kategorier af stimulus og eksempler på tilhørende svar tilhørende en stimulus kategori, f.eks. stimulus Lære system features og svar hjælpe systemet reagerer på kontekst. Scenarie element Stimulus kilde Stimulus Miljø Artefakt Svar Beskrivelse Slutbrugeren Ønsker at: - Lære system features - Anvende systemet effektivt - Minimere effekten af fejl - Adaptere systemet - Føle fortrolig med systemet På kørselstidspunkt (runtime) eller konfigurationstidspunkt (configure time) System Systemet giver et eller flere af følgende svar: 1. Understøtte lære nye system features : - hjælpe systemet reagerer på kontekst - brugeren er bekendt med interfacet - interfacet er brugbart i kendt kontekst 2. Understøtte anvende systemet effektivt : - aggregering af data og eller kommandoer - genbrug af eksisterende data og eller indtastede kommandoer - støtte med effektiv navigering indenfor en skærm - distinkte views med konsistente operationer - omfattende søgning - multiple simultane aktiviteter 3. At minimere effekten af fejl : - undo (fortryd) - cancel (annullere) - recover fra en system fejl - genkende og ret bruger fejl - frembringe glemte password Side 16 af 159

17 Svar måleenhed - verificere system ressourcer 4. At adaptere systemet - customizability - internationalization 5. At Føle fortrolig med systemet - fremvise systemets tilstand - arbejde med brugerens hastighed - Opgave tid (task time) - Antal af fejl - Antal af løste problemer - Brugertilfredshed - Tilvejebringelse af viden - Forholdet mellem succesfulde operationer og det totale antal af operationer - Tid anvendt eller data tabt Tabel 5: Generelt scenarie for usability scenarier [10]. Side 17 af 159

18 6 METODE I det efterfølgende afsnit beskrives metoden anvendt i projektet. 6.1 PROJEKTFASER Metoden opdeler projekt aktiviteter i faserne: foranalyse, eksperiment og evaluering, se Figur 4 Foranalyse Eksperiment Evaluering Figur 4: Projekt faser. I det efterfølgende beskrives de detaljerede aktiviteter for de enkelte fase. 6.2 FORANALYSE Inden projektet påbegyndes en foranalyse, der afklare om der er tilstrækkelig materiale til gennemførelsen af projektet, Figur 5. Hvis det viser sig, at der ikke kan findes tilstrækkeligt med materiale forkastes problemstillingen. Kriterier Notationen Firkant: Aktivitet Trekant: Beslutning Firkant med afrundede hjørner: Artefakt Informationsindsamling Beslutning go / no go Evaluering Udvælgelse Teknologi kandidat Teknologi kandidater Teknologi kandidater Figur 5: Foranalyse aktiviteter og artefakter. Hvis der i foranalysen findes baggrund for at fortsætte projektet inddeles forløbet i to mindre forløb. Det første forløb omhandler teori beskrivelse og analyse af, hvilke cloud computing teknologier, der findes på markedet og hvordan de relaterer til teorien, der anvendes. Denne del af projektet afgrænses af en tidsperiode til afsøgning af internet og gennemlæsning af materiale af interesse. Resultatet af dette forløb er en summarisk vurdering Side 18 af 159

19 og kategorisering af de enkelte teknologier. Med hjælp fra kategoriseringen udvælges en teknologi til det videre arbejde i næste forløb. 6.3 EKSPERIMENT OG EVALUERING Anden del af projektet er eksperimentel, og baseres på den udvalgte teknologi, der tages i brug og evalueres yderligere ud fra kvalitetsattributter baseret på usability kvalitetsattribut scenarier, Figur 6. Kriterier Udvikle Case Evaluering Modenheds kvalificering Figur 6: Fremgangsmåde for den eksperimentelle del af projektet Når den udvalgte teknologi kendes beskrives en case som ramme for realiseringen af en prototype. Løbende vurderes teknologien ud fra erfaringerne. Når kandidaten er identificeret, forsøges det at få softwaren aktiveret og afhængig af tiden udvælges et eller flere aspekter af teorien til realisering. Denne del af projektforløbet er den sværeste at forudsige, fordi teknologien kan være meget kompleks og den kan være abstrakt, så der skal skrives meget kode for at se en lille del af teorien virke eller den kan være konkret og fokuseret på et bestemt forretningsområde, som kan udnyttes og med få ressourcer afprøve detaljerede eksempler. Erfaringer, informationer og observationer, der har indgået i arbejdet, opsamles løbende i alle faser af projektet og dokumenteres endeligt i rapporten. Side 19 af 159

20 6.4 KVALITETSATTRIBUT SCENARIER I dette afsnit beskrives usability attribut kvalitets scenarier, som anvendes til evalueringen af den udvalgte teknologi i eksperimentet i afsnit 7.2 og 7.3. Disse er de generelle scenarier, som ikke specialiserede for den udvalgte kandidat Usability scenarie 1: Opsætning af udviklingsmiljø Teknologien er konfigureret og runtime environment er i orden, så alle afhængigheder er på plads og de grundlæggende services kan starte. Eclipse er konfigureret med alle afhængigheder. Når en teknologi specifikt interface kan realiseres uden anmærkninger, så er opgaven løst. Kilde Stimulus Artefakt(er) Miljø Respons Måling Forfatteren af rapport og udvikleren af case Tilegne grundlæggende kendskab til artefakter og strukturer. Dokumentation og eksempler. Linux / Windows platform. Artefakter giver det nødvendige struktureret overblik. Vurderingen sker ud fra forbrugt tid målt i dage og forventes afsluttet inden 3 dage (21 timer) Usability scenarie 2: Udvikling af første services Der arbejdes med at få et afgrænset artefakt at virke. Eksempelvis kan der arbejdes videre med det realiserede interface fra det foregående scenarie. Første interaktion afslutter opgaven. En log besked fra teknologien, der viser en service er registreret eller andet der viser en besked er sendt og modtaget fra teknologien til den nye klasse eller omvendt. Kilde Stimulus Artefakt(er) Miljø Respons Måling Forfatteren af rapport og udvikleren af case Lære at lave services, der kommunikerer med hinanden. Kodegenerering, command line interface, associeringsfunktionalitet Linux / Windows platform, med udviklingsmiljø konfigureret. Understøttelse for udvikling af interservice kommunikation. Opgaven skal udføres på under 7 timer Usability scenarie 3: Tilvejebringelse af instanser I dette scenarie skal virtuel maskine instanser oprettes og konfigureres med Java runtime miljø for udrulning af komponenter. Kilde Stimulus Artefakt(er) Miljø Respons Måling Forfatteren af rapport og udvikleren af case Lære at oprette og konfigurere instanser Fejlhåndteringsfunktionalitet Linux / Windows platform, med udviklingsmiljø konfigureret. Understøtte oprettelse og konfiguration af instanser Opgaven skal kunne udføres på under 7 timer. Side 20 af 159

21 6.4.4 Usability scenarie 4: Overvågning og SLA Der arbejdes med at lære at realisere SLA og politikker. Kilde Stimulus Artefakt(er) Miljø Respons Måling Forfatteren af rapport og udvikleren af case Lære at bruge politikker og service level agreements (SLAs) Politikker og SLAs Linux / Windows platform, med udviklingsmiljø konfigureret. Understøtte definition af SLA og politikker herunder monitorering af services Opgaven skal kunne udføres på under 7 timer. Side 21 af 159

22 6.5 EVALUERINGSTAKSONOMI I dette afsnit beskrives taksonomien, som anvendes i klassificeringen og evalueringen af teknologi kandidaterne. Figur 3 angiver taksonomien, som anvendes til klassifikation og evaluering af teknologierne. Taksonomien er baseret på [3, 4, 26] og kvaliteter vedrørende brugeopfattelse og anvendelse herunder usability. Teknologi Arkitektur Kvalitetsattri buter Brugerunder støttelse Vedligehold else Governance Licensmodel Standarder Anvendelses domæne Værktøjsund erstøttelse Platform Design mønstrer Komponent Usability Dokumentati on Fejl Plan Kommerciel Kommerciel Kommerciel IDE Operativ system Self Configuratio n Interface Scenarier Wiki Versioner Roadmap Åben Åben Forskning Debug Sprog Self Healing Opførsel Eksempler Nyeste version Udrulning Self Optimisation Etablering af interaktioner Manualer Self Protection Figur 3: Teknologi evalueringstaksonomi. Der anvendes 10 overordnede kategorier, som yderligere er underkategoriseret. Indledning (resume) Kortfattet beskrivelse af produktet. Platform Med dette menes udviklingsplatform herunder sprog f.eks. Java. Anvendelsesdomæne Med dette menes f.eks. forretnings- eller forskningsområde. Licensmodel Med dette menes overordnet om produktet er gratis eller kommerciel. Styringsmyndighed Med dette menes organisationsunderstøttelse og styring og kontrol med produktet. Vedligeholdelse Med dette menes styring af fejl, antallet af versioner og seneste version. Side 22 af 159

23 Understøttede standarder Med dette menes eventuelle specifikationer realiseret. Brugerunderstøttelse Med dette menes dokumentation herunder: wiki, eksempler, manualer og andet. Værktøjsunderstøttelse Med dette menes f.eks. udrulning, IDE integration, debugging, test etc. Arkitektur Med dette menes, hvordan teorien understøttes og udvalgte arkitekturegenskaber og nøgleinformationer. Her undersøges i forhold til [3,4] og krav til en autonom arkitektur i afsnit 5.2. Kvalitetsattributter Kvaliteter relevante herunder brugbarhed usability scenarier. Side 23 af 159

24 7 ANALYSE OG RESULTATER Dette afsnit indeholder en analyse af problemstilling og løsningsresultater. 7.1 FORANALYSE Dette afsnit indeholder foranalysen for projektet. Her evalueres fundne teknologi kandidater og en kandidat udvælges herfra til eksperiment fasen, som skal afklare og evaluerer kvaliteter vedrørende brugbarhed herunder usability Kandidater Nedenstående Tabel 3 er brutto kandidatlisten, som er fremkommet dels ved at følge eksisterende framework surveys [18, 19] og relevant information indenfor cloud computing [7, 17]. I alt er en liste på 21 kandidater fundet, som er baseret på Platform as a Service (PaaS) og Infrastructure as a Service (IaaS). Id Navn Type Licens model Organisation K1 Azure [27] PaaS Kommerciel Microsoft Corporation K2 Elastic Compute Cloud (EC2) [28] IaaS Kommerciel Amazon K3 App Engine [29] PaaS Kommerciel Google K4 Network.com (Sun Grid) [30] PaaS Kommerciel Sun Microsystems Incorporated, Oracle K5 Aneka [31] PaaS Kommerciel Udviklet i forskningsprojekt i GRIDS Lab, Melbourne universitet, omdøbt i 2009 til CLOUDS Lab ( kommercielle interesser varetages af Manjrasoft (CEO Buyya) K6 GoGrid [32] IaaS Kommerciel GoGrid K7 Flexiscale [33] IaaS Kommerciel Flexiant K8 Mosso / Rackspace [34] IaaS Kommerciel Mosso er en underafdeling af Rackspace K9 Gigaspaces [35] PaaS Kommerciel Gigaspaces K10 RightScale [36] PaaS Kommerciel RightScale K11 Force.com [37] SaaS Kommerciel Salesforce K12 Eucalyptus [38] IaaS Open source Eucalyptus Systems K13 OpenNebula [39] IaaS Open source OpenNebula.org Kommercielle interesser varetages af C12G Labs K14 Nimbus [40] IaaS Open source Nimbus.org K15 Enomaly [41] IaaS Open source Enomaly K16 ElasticHosts [42] IaaS Kommerciel ElasticHosts Side 24 af 159

25 K17 Exaweb [43] IaaS Kommerciel Exaweb K18 Stormondemand [44] K19 Layered Technologies [45] IaaS Kommerciel Storm on demand er en underafdeling af Liquid Web Inc IaaS Kommerciel Layered Tech K20 Joyent [46] IaaS Kommerciel Joyent K21 Heroku [47] PaaS Kommerciel Heroku, ejet af Salesforce.com Tabel 3: Cloud computing teknologi brutto kandidater. I forhold til projekt metoden udgør denne kandidat liste beslutningsgrundlaget for om et passende sæt af teknologier findes, som kan behandles i rapporten og om disse har de generelle ønskede self managed arkitektur og cloud computing egenskaber. Det vurderes ud fra dokumentationen for disse kandidater, at der kan forsættes med de næste analyse aktiviteter Evaluering Fra brutto kandidat listen Tabel 3 er nedenstående kandidater Tabel 4 udvalgt til efterfølgende evaluering. Id Navn Type License model Organisation K1 Azure [23] PaaS Kommerciel Microsoft Corporation K2 Elastic Compute Cloud (EC2) IaaS Kommerciel Amazon [24] K3 App Engine [25] PaaS Kommerciel Google K20 Joyent [42] IaaS Kommerciel Joyent K21 Heroku [43] PaaS Kommerciel Heroku Tabel 4: Kandidat liste til evaluering. Denne første udvælgelse er baseret på en tids afgrænset vurdering af elementerne i evalueringstaksonomien afsnit 6.5. Denne evaluering har til formål at begrænse bruttolisten til 5 kandidater for efterfølgende evaluering. Kandidaterne K4-K19 er fravalgt pga.: - Udgået teknologi (K4) - En rammeværk teknologi, men ikke er public cloud (K12, K13, K14, K15, K5, K9, K10) - Anvendelse af proprietær teknologi (K11), som ikke tillader åben udvikling på platformen - Mangler bruger brugerdokumentation og værktøjsunderstøttelse (K6, K7, K16, K17, K18), - De efterfølgende har Ikke fyldestgørende opfyldelse af cloud computing og self managed egenskaber (K6, K7, K8, K16, K17, K18, K19) I det efterfølgende evalueres de 5 udvalgte teknologier. Side 25 af 159

26 7.1.3 Microsoft Azure Indledning Microsoft Windows Azure beskrives som: et operativ system som en service [53] afviklet på Microsoft datacentrer. Det kan anvendes til udvikling, udrulning, styring og distribution af applikationer og services på internettet. Microsoft Azure er sammensat af Azure fabric bestående af computer og lagringsressourcer samt platform services ved en service bus og adgangskontrol. Platform Microsoft Azure understøtter forskellige teknologier afhængig af hvilken virtuel maskine rolle, der anvendes. Web rollen understøtter vha. Internet Information Services (IIS) [59]: -.Net - Java - PHP - Ruby Og andre teknologier understøttet af IIS. Anvendes Worker rollen er det muligt at afvikle et givent runtime miljø baseret på Windows operativ system, f.eks. Tomcat, vha. Worker process applikation interface. Integration kan foretage manuelt eller vha. Solution Accelerator koncept. VM rollen tillader at levere et Windows Server virtuel maskine image til afvikling af Virtual Machine Monitor. Anvendelsesdomæne Microsoft Azure kan anvendes til udvikle forskellige typer af applikation [53]: - En uafhængig software leverandør (independent software vendor - ISV) kan udvikle applikationer målrettet forretningsbrugere. Software as a Service (SaaS) - En ISV kan målrette en SaaS applikation til forbruger grupper - Organisationer kan anvende Microsoft Azure til udvikling af applikationer til ansatte En anvendelsesmodel for Microsoft Azure er vist på Figur 7. Side 26 af 159

27 Figur 7: Microsoft Azure anvendelsesmodel [53]. Licensmodel Microsoft anvender to forskellige betalingsmodeller [57]: Forbrugsmodel: med denne model betales for det faktiske forbrug Pay as you go. Metrikkerne kan f.eks. være timeforbrug, antal transaktioner eller lagringsstørrelse i GB. Abonnentmodel: Der betales et fast månedligt beløb mellem $60-$100, hvormed der betales for en fast kvote f.eks. antal CPU timer eller transaktioner. Overskrides kvoten betales den normale forbrugspris for ressourcen. Dermed kan der opnås en besparelse på mellem 25 % -56 % i forhold til normal forbrugspris. Prisen er mellem $60-$100 og forbrugeren bindes til en 6 måneders betalingsperiode. Figur 8 og Figur 9 beskriver forbrugspriser for virtuelle maskine instanser og dataoverførsel ind og ud af datacenter. Derudover betales for tillægsservices som f.eks. lagring herunder database og adgangskontrol og service bus. På lagringsresurser og andre services betales desuden også for antal transaktioner udført. Instans type Medium Large Extrasmall Small Extralarge CPU Hukommelse Instans lager I/O ydelse kategori Pris pr. time single-core 1.0 GHz CPU 768MB 20GB Lav $0.05 single-core 1.6 GHz 1.75 GB 225 GB Moderat $0.12 CPU dual-core 1.6 GHz 3.5 GB 490 GB Høj $0.24 CPU four-core 1.6 GHz 7 GB 1000 GB Høj $0.48 CPU eight-core 1.6 GHz 14 GB 2040 GB Høj $0.96 CPU Figur 8: Instans typer og forbrugspriser [57, 58]. Side 27 af 159

28 Region Ud af datacenter pris Ind til datacenter pris Nord Amerika og Europa $0.15 / GB $0.10 / GB Asien $0.20 / GB $0.10 / GB Figur 9: Dataoverførselspriser mellem forbruger og datacenter fordelt på regioner [57]. Standarder Microsoft Azure er baseret på.net teknologi, men andre teknologier understøttes, som f.eks. Java. Service interfaces er beskrevet med Web Services standard REST eller egne standarder som f.eks. TDS for database service. Styringsmyndighed Microsoft Azure teknologier er styret af Microsoft corporation. Vedligeholdelse Teknologien har tilknyttet software til platformen og udviklingsværktøjer. Figur 10 og Figur 11 viser antal udgivne versioner af software for hhv. Microsoft Azure SDK og opdateringer af virtuel maskine operativ system software. Version 1.0 af SDK og operativ system blev frigivet i hhv. november 2009 og december Der har i perioden været 12 opdateringer af OS software af typen sikkerhedsopdatering. SDK software er udgivet i 4 versioner og har ifølge release note beskrivelser været af en karakter, hvor SDK opdateres til den seneste.net frigivelse. Version Dato Beskrivelse 1.3 November Opdatering ift..net framework Juni 2010 Opdatering ift..net framework 1.1 Februar 2010 Opdatering ift..net framework 1.0 November Opdatering ift..net framework 2009 Figur 10: Microsoft Azure SDK versioner [61]. Version Dato Beskrivelse 2.1 December November December 2010 Stabilitets og sikkerhedsopdatering Stabilitets og sikkerhedsopdatering Stabilitets og sikkerhedsopdatering 1.8 November Stabilitets og sikkerhedsopdatering Oktober 2010 Stabilitets og sikkerhedsopdatering 1.6 September 2010 Stabilitets og sikkerhedsopdatering 1.5 Juli 2010 Stabilitets og sikkerhedsopdatering 1.4 June 2010 Stabilitets og sikkerhedsopdatering 1.3 April 2010 Stabilitets og sikkerhedsopdatering 1.2 April 2010 Stabilitets og sikkerhedsopdatering 1.1 Januar 2010 Stabilitets og sikkerhedsopdatering Side 28 af 159

29 1.0 December Stabilitets og sikkerhedsopdatering 2009 Figur 11: Microsoft guest VM operativ system versioner [62]. Der er mulighed for at følge Microsoft Azure services status på Services status dashboard [60] også i et historisk perspektiv. Microsoft Azure har Service Level Agreement - SLA[52] beskrevet for de enkelte services. I for hold til data sikkerhed er en flere af datacentrer certificeret i ISO [63] en management standard for data sikkerhedshåndtering. Desuden opfyldes Safe Harbor principperne, som er Amerikansk og Europæisk proces principper udviklet for, at amerikanske organisationer kan overholde de europæiske direktiver om personlig data sikkerhed. Microsoft Azure datacentrer findes i flere regioner herunder: USA, Europa og Asien [64]. USA er opdelt i zonerne, syd central USA, nord central USA. Europa er opdelt i zonerne: nord Europa og vest Europa. Asien er opdelt i zonerne: syd øst asien og øst asien. Brugerunderstøttelse Brugeren understøttes i udvikling vha. forskellige kanaler og medier. Der findes bl.a. dokumentation for Software Developer Kit og services API [48]. Nedenfor er en listet yderligere information til rådighed. - Video - Kode eksempler - Ofte stillede spørgsmål (FAQ) - White papers - Artikler - Best practices - Gettting started guide - Service interface beskrivelse, API - Software Developer Kit (SDK) dokumentation - Forum - Community - Microsoft Developer Network (MSDN) Side 29 af 159

30 Værktøjsunderstøttelse Platformen er baseret på.net og hertil findes et SDK og understøttelse i IDE Visual Studio. Herudover er der frigivet SDK til Ruby, Java og PHP. Derudover er der understøttelse for udvikling i IDE Eclipse. Arkitektur Windows Azure platformen ses på Figur 12. Detalje beskrivelse findes i hhv. [49], [50] og [53]. På Figur 12 vises, hvorledes det er muligt at have forskellige konfigurationer af applikationer tilknyttet cloud. Applikationer i en virksomhed (On-Premises) kan anvende services fra cloud f.eks. lagring vha. SQL Azure eller applikationer kan afvikles i cloud (Off-Premises). Figur 12: Windows Azure platformen [50]. Windows Azure platformen indeholder 3 komponenter, som yderligere er underopdelt: 1. Windows Azure Denne komponent udbyder et Windows miljø til afvikling af applikationer og lagring af disses data. På Figur 13 ses, at denne indeholder 5 delkomponenterne. Figur 13: Windows Azure komponent [49]. Side 30 af 159

31 Compute Afvikler applikationer i cloud i et miljø, der svarer til et Windows Server miljø med ændringer, som krævet af Windows Azure programmeringsmodellen. Applikationen skal implementeres og afvikles efter en rolle, se Figur 14. Figur 14: Windows Azure applikation konfiguration og roller [49]. Windows Azure kan afvikle flere instanser af hver rolle og dermed distribuere arbejdsbelastning til hver instans vha. en load balancer. Windows Azure understøtter 3 roller. Web rolle: Denne anvendes ved udvikling af web baserede applikationer. Til denne rolle er der tilknyttet en web server service ved Internet Information Services (IIS). Applikationer kan udvikles, som anvender forskellige web teknologier herunder ASP.NET, Windows Communication Foundation (WCF),.NET Framework og ikke Microsoft specifikke teknologier som Java og PHP, som kan afvikles i IIS. Worker rolle: Modsat Web rollen, så har denne rolle ikke en IIS tilknyttet. Rollen kan varetage f.eks. den domæne specifikke del af applikationen f.eks. afvikle en algoritme, som brugeren har forespurgt via Web rollen, og som videresendes til worker rollen. Applikationen, som worker rollen afvikler, kan udvikles i Microsoft specifikke teknologier, som f.eks..net Framework eller ikke Microsoft specifikke teknologier, som f.eks. Java. VM rolle: Denne rolle afvikler et af brugeren leveret Windows Server 2008 R2 virtuel maskine image. Dette gør det muligt at flytte en applikation fra virksomheden (on-premises) til Windows Azure. Applikation publiceres til Microsoft Azure vha. Portal [51] eller udviklingsmiljøet. En konfigurations fil bestemmer antallet af instanser, som hver rolle skal opstarte. Fabric controller opretter en virtuel maskine (VM) for hver instans af applikationen for den givne rolle. En load balancer sender bruger forespørgsler til forskellige instanser af en given rolle, derfor bliver forespørgsler fra en given bruger ikke Side 31 af 159

32 nødvendigvis sendt til den samme instans af en given rolle. Applikationen må derfor ikke vedligeholde tilstand mellem forespørgsler, men i stedet gemme klient tilstand information til f.eks. SQL Azure for andre instanser. Stiger belastningen for applikationen, så kan udvikleren eller en anden rolle, anvende Microsoft Azure Portal [51] til at hæve antallet af instanser for applikationen og tilsvarende reducere antallet af instanser, når belastningen falder igen. Dette kan også gøres i applikationen vha. interface til Fabric controller, men Windows Azure skalerer ikke automatisk op og ned. Hver instans kan kalde et logging interface for derved at gemme information for applikationen i en global log. Desuden kan der indsamles information fra tællere (counters) om applikation f.eks. CPU forbrug, crash dumps etc. Denne information gemmes i Windows Azure storage. Storage Azure storage tilbyder flere lagringsmuligheder og typer, som det ses i Figur 15. Figur 15: Windows Azure storage elementer [49] Blobs: Dette er den simpleste måde at lagre data på. En blob indeholder binær data og er struktureret som et hierarki, hvor en container kan indeholde en eller flere blobs, som vist på Figur 15. Blobs kan have en størrelse på 1 TB og have tilknyttet metadata, som beskriver data med f.eks. tid og sted. Desuden er blobs lagringsmedie for rolle instanser, kaldet Windows Azure drives, og tillader operationer som svarer til et lokal fil system. Tables: Tillader at strukturere data i tabeller, dog ikke som relationelle tabeller. Data i tabeller lagres i entities, som indeholder properties. Data kan distribueres over mange maskiner (scale-out). Data forespørges vha. konventioner defineret af OData (Open Data Protcol) [54]. Queues: Message queues tillader f.eks. Web rolle instanser at kommunikere med Worker rolle instanser asynkront. En bruger kan dermed via Web interface til Web rolle instans forespørge en tidskrævende opgave, som denne skriver på message queue. En Worker rolle, som læser på message Side 32 af 159

33 queue, kan dermed udføre opgaven og resultatet evt. skrives på en anden message queue. Data indeholdt i Azure storage elementer bliver kopieret 3 gange. Microsoft har en backup af data i et andet data center i den samme del af verdenen. Windows Azure storage er tilgængelig via HTTP og overholder REST konventionerne. Fabric Controller Windows Azure platformen, som findes i data centret, bliver styret af en central komponent, kaldet Fabric Controller. Denne styrer maskinerne samt softwaren tilknyttet disse, som Windows Azure platformen afvikles på. Figur 16 viser dette. Figur 16: Fabric Controller [49]. Fabric Controller er distribueret over en gruppe af maskiner og kommunikerer med hver virtual machine (VM) via en Fabric agent. Fabric Controller har til opgave at monitorer alle applikationer og VMs og bestemmer, på hvilken maskine en applikation skal afvikles. Dette afgøres ud fra en konfigurations fil baseret på XML, som uploades sammen med hver applikation. Heri beskrives kravene til applikationen herunder f.eks., hvor mange Web rolle instanser der kræves af applikationen. Fabric Controller anvender denne information til at bestemme, hvor mange VMs, der skal oprettes. Hvis en instans fejler, så starter Fabric Controller en ny og forbinder Load Balancer med denne. Desuden håndterer Fabric Controller opdatering VM operativ system, som Web rolle og Worker rolle afvikles på. Dette kræver 2 instanser af en given applikationer ellers er applikationen ikke tilgængelig, når opdatering foregår. Fabric Controller understøtter oprettelse af følgende VM konfigurationer, Tabel 5. Instans type CPU Hukommelse Instans lager Extra-small single-core 1.0 GHz CPU 768MB 20GB Small single-core 1.6 GHz CPU 1.75 GB 225 GB Medium dual-core 1.6 GHz CPU 3.5 GB 490 GB Large four-core 1.6 GHz CPU 7 GB 1000 GB Extra-large eight-core 1.6 GHz CPU 14 GB 2040 GB Tabel 5: VM konfigurationer [49]. Side 33 af 159

34 Content Delivery Network (CDN) CDN forbedrer tilgangen til blob data i Windows Azure storage ved at vedligeholde flere kopier af data (cache) omkring i verden. Dette muliggøres ved et content delivery network (CDN), som er så geografisk tæt på brugeren som muligt. Dette er vist på Figur 17. Figur 17: Content Delivery Network (CDN) [49]. Blob cache tæt på brugeren oprettes første gang denne tilgår data. Næste gang hentes data fra cache i stedet for originalen længere væk. Connect Muliggør at oprette IP forbindelser mellem computere i virksomheder (onpremises) og Windows Azure applikationer, således at disse fremkommer at være on-premises. Dette er vist på Figur 18. Figur 18: Connect [49]. Dette er VPN (Virtual Private Network) lignende funktionalitet, således at Windows Azure applikationer fremstår som at være på det samme IP netværk, som on-premises maskinen. Dette tillader f.eks. en Azure applikation, som før var on-premises, at tilgå en database uden at foretage Side 34 af 159

35 forbindelses ændringer. Brugere kan også foretage single sign-on og Azure applikationen har tilgang til adgangskontrolsystemer on-premises. Dette kræver installation af en Endpoint agent på on-premises maskinen, som forbindes med Azure applikationen og understøttelse af IPv6. Herefter kan en IPsec forbindelse oprettes. 2. SQL Azure Denne komponent udbyder data services baseret på Microsoft SQL Server. Den består af delkomponenterne: - SQL Azure database - Og andre fremtidige muligheder som data synkronisering, rapportering og data analyse SQL Azure database tilbyder et database management system (DBMS), som muliggør on-premises eller cloud applikationer at lagre relationel data. SQL Azure database ses i Figur 19. Figur 19: Azure SQL [50]. En applikation som er on-premises, i Windows Azure eller andre steder, kan tilgå database vha. en protokol kaldet Tabular Data Stream (TDS), som også anvendes i Microsoft SQL Server. Derfor vil applikationer, der anvender Microsoft SQL Server, også kunne anvende SQL Azure Database og det samme software, som ODBC, ADO.NET og andet. Der er begrænsninger i den første, som betyder understøttelse for spatial data og SQL Common Language Runtime (CLR) mangler. Den maksimale størrelse på en database er 10GB, kræves mere skal flere databaser anvendes. En forespørgsel kan også kun køre i en begrænset tid. Data kopiers 3 gange, som i Azure Storage. 3. Windows Azure platform AppFabric Denne komponent udbyder services til at forbinde applikationer som afvikles i virksomheden (on-premises) eller i cloud (off-premises). Den består af delkomponenterne: Side 35 af 159

36 Service bus Denne delkomponent tillader applikationer at udbyde deres interfaces (endpoints), således, at de kan benyttes af andre applikationer i virksomheden eller i cloud. Hver applikations endpoint tildeles en URI, som klienter kan anvende til at lokalisere og benytte applikationen. Service bus er desuden ansvarlig for at oversætte netværks adresser, network address translation (NAT), og adgang gennem firewalls uden at åbne nye porte for applikationen. Service bus struktur ses på Figur 20. Figur 20: Service Bus [50]. Service Bus opfylder ansvar efter 5 trin, som vist på Figur Applikationen registrerer endpoint i Registry 2. For hvert registreret endpoint udbyder Service Bus et endpoint og tildeler en URI root, som tillader endpoint at blive søgbart (discoverble). Applikationen skal åbne en forbindelse til Service Bus til hvert endpoint, som den udbyder. Service Bus holder denne forbindelse åben, hvilken tillader trafik at blive sendt til applikationen. Da applikationen har oprettet en forbindelse indenfor firewall, så vil den tillade trafik at blive sendt hertil. Dermed er NAT problem løst. 3. Når en klient ønsker at benytte en specifik service (applikation), kontaktes Registry for at modtage endpoint, hvorpå applikationen kan forbindes til. Klienten modtager en service beskrivelse vha. Atom Publishing Protocol (AtomPub / APP) [55] med referencer til endpoints og interface operationer, som applikationen tilbyder. 4. Klienten kan nu udføre operationer via Service Bus på den givne applikation. 5. Service Bus udfører modtagne operationer på applikationen. Når det er muligt forsøger Service Bus at oprette en direkte forbindelse mellem klient og applikation. Side 36 af 159

37 Access Control Denne delkomponent tillader en RESTful klient applikation at authenticate sig selv og tilbyde en server applikation information vedrørende identifikation om denne, således, at denne kan bestemme, hvilke rettigheder applikationen har. Access Control struktur ses på Figur 21. Figur 21: Access Control [50]. Access Control opfylder ansvar efter 5 trin, som vist på Figur Før klienten kan kommunikere med applikationen skal den have en token, som beskriver identifikation information om den. Denne information er udtrykt som en eller flere claims, som hver beskriver klienten. En claim kunne f.eks. indikerer, hvilken organisation, som denne klient applikation tilhører. Klienten modtager token af Access Control, når den er authenticated. Klienten bliver authenticated af Access Control, når den har sendt en 32bit key eller en token, som enten indeholder claims eller er beskrevet med Security Assetion Markup Language (SAML). 2. Når klienten er authenticated, så opretter Access Control endnu en token, som indeholder claims. Server applikationen kan bestemme regler for, hvordan denne token skal oprettes baseret, hvilken identifikation information den har leveret; en 32 bit key eller en token. 3. Når Access Control har oprettet en token, så sendes den til klienten 4. Klienten sender den modtagne token til server applikationen 5. Server applikationen validerer den modtagne token og anvender claims indeholdt heri til at bestemme klientens rettigheder. Side 37 af 159

38 Evaluering Microsoft Azure giver understøttelse for dele af autonomic computing kravene afsnit 5.2. Element: krav KO.1, KO.2 Selvkonfiguration Den enkelte service skal foretage konfiguration af service afhængigheder ved etablering af forbindelser til andre services vha. f.eks. service registry. Selvoptimering Azure foretager via Fabric Controller software opdatering af instanser. En load balancer fordeler forespørgsler til aktive instanser. Selvhealing Platformen har overvågning vha. Fabric Controller og kan erstatte en virtuel maskine, som ikke er i den rette tilstand. Selvbeskyttelse Azure tilbyder adgangskontrol til services vha. AppFabric Access Control. Relationer krav KO.3-7 Der er mulighed for service discovery ved AppFabric, men ikke forhandling af bedst egnede services. Politikker krav KO.8-18 Det er ikke muligt vha. politikker at bestemme, hvordan systemet skal opfører sig for f.eks. at sikre en service har en given svar tid eller CPU belastning. Udvikleren eller manageren af services i Microsoft Azure skal sikre, at der findes et passende antal virtuelle instanser. Interfaces krav KI.1-17 Platformen har overvågning vha. Fabric Controller og kan erstatte en virtuel maskine, som ikke er i den rette tilstand og sørger desuden for opdatering af operativ system. Det er ikke muligt for andre services at forespørge om den nuværende tilstand eller lifecycle model. Der er mulighed for indsamling af log information for den enkelte instans. System KS.1-5 Der tilbydes understøttende services fra AppFabric i form af service registry og adgangskontrol. Microsoft understøtter brugeren med forskellige typer af dokumentation herunder detaljerede platformbeskrivelser, SDK dokumentation, artikler og eksempler. Desuden kan brugeren interagerer vha. forum, netværk og community. Udviklingsmiljøet er baseret på.net og Visual Studio IDE, men Azure har mulighed for at installere f.eks. Java runtime miljø i et specielt setup. Microsoft vedligeholder SDK software og virtuel maskine OS software med en månedlig og kvartalslig frekvens. Side 38 af 159

39 Der er mulighed for at få afviklet software i Microsofts datacentrer i Europa også i Danmark. Datacentrerne er styret af sikkerheds- og management processer. Microsoft tilbyder forskellige konfigurationer af virtuelle instanser med forskellig CPU typer og hukommelse til et specifikt behov. Brugere kan vælge 2 prismodeller, hvor der enten afregnes efter en fast timepris eller en abonnent model, hvor der betales en fast månedlig pris for et givent antal forbrugstimer med en reduceret timepris Amazon EC2 Indledning Amazon cloud computing platformen er baseret på en samling af web services, Amazon Web Services (AWS) [98], som er kategoriseret i emnerne: computer ressourcer, lagrings ressourcer, beskeds håndtering ressourcer og andre. Computer ressourcen kaldes Elastic Computing Cloud (EC2) [66] og henviser til, at denne ressource kan udvides efter behov. Platform EC2 kan konfigureres til at anvende et givent operativ system for den virtuelle maskine. Der findes allerede konfigurerede virtuelle maskiner kaldet Amazon Machine Images (AMIs), som brugeren kan anvende [99]. Der er understøttelse for flere varianter af Linux, Unix og Windows [66]. Desuden er det muligt at konfigurere et AMI til et specifikt behov og upload dette til AWS. AMIs findes med software installeret f.eks. databaser og applikations miljøer herunder f.eks. Java runtime. Anvendelsesdomæne AWS beskrives som en infrastruktur web services platform, som kan tilbydes organisationer af forskellige størrelser. Computer, lagring og andre services kan købes efter forretningsbehov. Der er mulighed for at vælge udviklingsplatform og programmering model efter det specifikke behov. Forskellige forretningsområder nævnes, som målgrupper for den fleksible udvidelse af ressourcer, herunder e-handel, som ikke kan forudsige web trafik, farmaceutiske organisationer med behov for simulationer i stor skala og medie organisationer som kan levere video, musik og andet. Licensmodel Amazon beskriver 3 forskellige prismodeller for EC2 [97]. De benævnes: On demand instans: Der betales for timeforbruget for computer ressourcen og ingen fast abonnement pris. Spot instans: Det er muligt at byde på ubenyttet computer kapacitet. Prisen Side 39 af 159

40 opdateres af Amazon hver halve time. Historiske data er tilgængelig, således et bud kan forberedes. Et bud afgives med den maksimale pris for forbruget af en computer ressource. Hvis buddet matcher eller overstiger den nuværende pris, så bliver ressourcen reserveret. Den virtuelle maskine instans afvikles indtil den bliver stoppet eller prisen for ressourcen overstiger det afgivne bud. Reserved instans: Der foretages en engangsbetaling af 1 eller 3 års varighed og prisen for timeforbruget reduceres herefter. Engangsbetaling for den mindste (small) virtuelle maskine instans er $228 pr. år eller $350 for 3 år. Timeforbruget reduceres til $0.03 pr time for en Linux/Unix instans og $0.05 for en Windows instans. Amazon har 6 kategorier for virtuelle maskine instanser: - Standard - Micro - High-Memory - High-CPU, - Cluster Compute - Cluster GPU Alle henvendt til specifikke behov. I hver kategori findes forskellige virtuelle maskine instanser, som beskrives med en benævnelse, som f.eks. small og large. Dette henviser til konfigurationen af den virtuelle maskine herunder CPU og hukommelse. Amazon har defineret en computer enhed kaldet EC2 compute unit, hvilket svarer til GHz 2007 model Opteron, 2007 model Xeon processer eller 2006 model 1.7 GHz Xeon [96]. Hermed skal det ifølge Amazon være nemmere at sammenligne virtuelle maskine instanser på tværs af forskellige hardware platforme. Amazon prisafregner forbrug baseret på: virtuel instans type, geografisk region af datacenter, ønsket prismodel (spot instances, on demand og reserved) og platfrom (Linux/Unix eller Windows). Tabel 6 angiver priser for Linux/Unix og Windows baserede instanser, hvor Linux/Unix prisen er først angivet og Windows følger derefter. Den geografiske region er EU, Irland og prismodellen er on denmand. Instans type CPU Hukommelse Instans lager Micro Small Up to 2 EC2 Compute Units (for short periodic bursts) 1 EC2 Compute Unit (1 virtual core with 1 EC2 Compute Unit) I/O ydelse kategori Pris pr. time 613 MB Kun EBS Lav $0.025 / $ GB 160 GB Moderat $0.095 / $0.12 Side 40 af 159

41 Large Extra large High-Memory Extra Large High-Memory Double Extra Large High-Memory Quadruple Extra Large High-CPU Medium High-CPU Extra Large Cluster Compute Quadruple Extra Large 1 Cluster GPU Qua druple Extra Large 1 4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each) 8 EC2 Compute Units (4 virtual cores with 2 EC2 Compute Units each) 6.5 ECU (2 virtual cores with 3.25 EC2Compute Units each) 13 EC2 Compute Units (4 virtual cores with 3.25 EC2 Compute Units each) 26 EC2 Compute Units (8 virtual cores with 3.25 EC2 Compute Units each) 5 EC2 Compute Units (2 virtual cores with 2.5 EC2 Compute Units each) 20 EC2 Compute Units (8 virtual cores with 2.5 EC2 Compute Units each) 33.5 EC2 Compute Units (2 x Intel Xeon X5570, quadcore Nehalem architecture) 33.5 EC2 Compute Units (2 x Intel Xeon X5570, quadcore Nehalem architecture, 2 x NVIDIA Tesla Fermi M2050 GPUs) 7.5 GB 850 GB Høj $0.38 / $ GB 1690 GB Høj $0.76 / $ GB 420 GB Moderat $0.57 / $ GB 850 GB Høj $1.14 / $ GB 1690 GB Høj $2.28 / $ GB 350 GB Moderat $0.19 / $ GB 1690 GB Høj $0.76 / $ GB 1690 GB Meget høj (10 Gigabit Ethernet) 22 GB 1690 GB Meget høj (10 Gigabit Ethernet) Tabel 6: Instans typer og forbrugspriser [ec32, 33], on demand i EU. 1 Kun tilgængelig i Nord Virgina. 2 Windows understøttes ikke Udover forbrug for computer ressourcer afregnes der også på datatrafik mellem datacentrer i forskellige regioner. Priserne for dette ses i Tabel 7. Region Ud af datacenter pris Ind til datacenter pris Nord Amerika og Europa Første GB / md. : $0.00 / GB Op til 10 TB / md. : $0.15 / GB Næste 40 TB / md. : $0.11 / GB Næste 100 TB / md. : $0.09 / GB Næste 150 TB / md. : $0.08 / GB $0.10 / GB $1.60 / 2 $2.10 / 2 Side 41 af 159

42 Asien Første GB / md. : $0.10 / GB $0.00 / GB Op til 10 TB / md. : $0.19 / GB Næste 40 TB / md. : $0.15 / GB Næste 100 TB / md. : $0.13 / GB Næste 150 TB / md. : $0.12 / GB Tabel 7: Dataoverførselspriser mellem forbruger og datacenter fordelt på regioner [97]. Der afregnes ikke forbrug mellem EC2 og andre Amazon web services indenfor den samme region. Standarder AWS er baseret på web services teknologi og alle services har interfaces beskrevet efter web services specifikation REST eller SOAP. Styringsmyndighed AWS styres af Amazon Web Services Limited Liability Company (LLC) ejet af Amazon.com incorporated. Vedligeholdelse AWS har tilknyttet udviklingsværktøj kaldet AWS toolkit. Dette toolkit findes til flere udviklingsplatforme herunder Java. Herudover vedligeholdes interfaces også for de enkelte services. Nedenfor i Tabel 8 og Tabel 9 er vist versionshistorikken for disse. Version Dato Beskrivelse December Seneste version. Opdatering af SimpleDB November Understøttelse af S3 mulitpart upload API Oktober 2010 Opdatering Elastic Map Reduce, EMR klient og SimpleDB quoting og escaping af værdier i queries Oktober 2010 Understøttelse af RDS read replica DB instanser, HTTPS load balancers, S3 klient med kryptering. Generel opdatering September Understøttelse af EC2 tagging. Generel opdatering September Generel opdatering September 2010 Understøttelse af ny AWS Identity and Access Management (IAM). Generel opdatering August 2010 Understøttelse af den seneste API version af RDS, og reserved DB instanser. Generel opdatering Juli 2010 Generel opdatering Juli 2010 Generel opdatering Juni 2010 Generel opdatering Maj 2010 Generel opdatering April 2010 Generel opdatering April 2010 Generel opdatering April 2010 Generel opdatering Side 42 af 159

43 Marts 2010 Første version Tabel 8: Amazon Web Services Java toolkit [100]. I alt er det frigivet 16 versioner af Java toolkit med den seneste i december Den første frigivelse var i marts Opdateringer er af forskellig karakter fra fejlrettelser til opdateringer i forhold til service interface ændringer. Siden marts 2010 er der blevet frigivet versioner på måneds basis. Version Dato Beskrivelse 19 November /AmazonEC2.wsdl 18 August /AmazonEC2.wsdl 17 Juni /AmazonEC2.wsdl 16 November /AmazonEC2.wsdl 15 Oktober /AmazonEC2.wsdl 14 August /AmazonEC2.wsdl 13 Juli /AmazonEC2.wsdl 12 April /AmazonEC2.wsdl 11 Marts /AmazonEC2.wsdl 10 December /AmazonEC2.wsdl 9 August /AmazonEC2.wsdl 8 Maj /AmazonEC2.wsdl 7 Februar /AmazonEC2.wsdl 6 August /AmazonEC2.wsdl 5 Marts /AmazonEC2.wsdl 4 Januar /AmazonEC2.wsdl 3 Januar /AmazonEC2.wsdl 2 Oktober /AmazonEC2.wsdl 1 Juni /AmazonEC2.wsdl Tabel 9: EC2 service interface versioner (WDSL) [101]. Der er frigivet 19 EC2 WDSL service interface versioner. Den seneste er frigivet i november 2010 og den første i juni Der anvendes både en måneds- og kvartals baseret frigivelsesplan. Hvis man sammenlægger EC2 service interface frigivelser med andre service API frigivelser fås i alt 41 frigivelser over perioden. Side 43 af 159

44 Der er mulighed for at følge Amazon Web Services status på Service Health Dashboard [79] også i et historisk perspektiv. Amazon Web Services har Service Level Agreement - SLA[94] beskrevet for de enkelte services. Amazons datacentrer er certificeret i ISO og opfylder Safe Harbor principperne [102]. Amazons datacentrer er placeret i 4 geografiske regioner: USA (øst, Nord Virginia og vest, Nord Californien), EU (Irland) og Asien (Singapore). Hver af disse regioner er yderligere opdelt i availability zoner [102], 4 zoner for USA øst, 3 zoner for USA vest og 2 zoner i EU og Asien. Brugerunderstøttelse Services beskrives med følgende elementer: - Interface beskrivelse Web Services Specification Desription Language (WDSL) [92] - Release notes - Dokumentation (Getting started guide, Developer guide, user guide, API reference, command line reference, quick reference card) Derudover findes generel information: - Community forum tilbyde Amazon udviklere kode til AWS toolkit, feature requests, spørgsmål - Artikler - Video - Turtorials - Kode eksempler - Support - Issue tracker - Ofte stillede spørgsmål (FAQ) - User groups - Blog Værktøjsunderstøttelse Der findes AWS SDK til - Java (og Eclipse), - PHP, Side 44 af 159

45 - Ruby -.NET, - Python - Mobile (Android, ios) Der findes API tools til : - Command line værktøjer Arkitektur Amazon cloud computing [90, 91] teknologi er baseret på web services [93] og er samlet benævnt Amazon Web Services (AWS). Den grundliggende arkitektur for cloud computing er vist i Figur 22. Figur 22: AWS arkitektur[65]. Arkitekturen kan opdeles i 3 komponenter compute, storage og understøttende services. Compute Amazon Elastic Compute Cloud (EC2) [66] service udbyder et system virtual machine miljø til afvikling af applikationer. Der er understøttelse for Windows og Linux operativ systemer og forskellig konfiguration af disse kan vælges i Amazon Machine Images (AMI) med teknologi planforme installeret f.eks. Java eller specifikke databaser. Desuden er det muligt at vælge og oprette et operativ system uden specifik konfiguration. Det er muligt at oprette, starte og stoppe VM instanser vha. Amazon Management Console[78] og fra web service interface fra en applikation. Mulige VM instanser ses i Tabel 10. Side 45 af 159

46 Instans type Micro Small Large Extra large CPU Hukommelse Instans lager Up to 2 EC2 Compute Units (for short periodic 613 MB Kun EBS bursts) 1 EC2 Compute Unit (1 virtual core with 1.7 GB 160 GB 1 EC2 Compute Unit) 4 EC2 Compute Units (2 virtual cores with 7.5 GB 850 GB 2 EC2 Compute Units each) 8 EC2 Compute Units (4 virtual cores with GB 2 EC2 Compute Units each) Tabel 10: VM konfigurationer, udvalgte [66]. Compute og storage services kan oprettes i forskellige geografiske lokationer, hvor de enkelte datacentrer er placeret. Lokationer findes i - USA: Northern Virginia og Northern California - Europa: Ireland - Asian Pacific (APAC): Singapore Amazon Elastic MapReduce [67] service udbyder et cluster af MapReduce VMs til behandling af store mængder af data. MapReduce framework er baseret på en Hanoop implementation. Et specifikt job (databehandlings applikation) og data til behandling uploades til Amazon Simple Storage Service (S3) og behandles i et cluster af VM Hanoop instanser. Data opdeles i et job flow i mindre dele til parallel behandling, hvilket kaldes map funktionen. De færdigbehandlede data dele samles igen, kaldet reduce funktionen, i S3. Amazon Auto Scaling [68] service tillader automatisk at skalere VM instanser op eller ned baseret på politikker, som defineret af CloudWatch [80] metrikker f.eks. CPU belastning. Det er desuden muligt at modtage notifikationer vha. Amazon Simple Notification Service (SNS) [77], når en auto scaling aktivitet foretages. Amazon Elastic Load Balancing [69] service fordeler automatisk data trafik til VM instanser og undlader at sende trafik til VM instanser, som bestemmes til at levere en forringet service. Dette defineres vha. metrikker leveret af CloudWatch service. Storage AWS tilbyder 5 storage service typer, som gennemgås nedenfor. Amazon SimpleDB [71] service er en ikke relational database, som desuden ikke er baseret på et skema. Data bliver automatisk indekseret. Databasen er key/value baseret og data placeres i et domain, svarer til en tabel, og tilknyttes attributes, svarer til felter. Items svarer til rækker. Amazon Elastic Block Store (EBS )[72] service tillader VM instanser at tilknytte en storage volume, som applikationen kan læse fra og skrive til. Data skrevet til EBS vil være tilgængelig efter VM instans er stoppet. EBS kan f.eks. anvendes til applikationer, der kræver en database eller et Side 46 af 159

47 filsystem til lagring. En VM instans kan have tilknyttet flere EBS volumer, men en volume kan kun være tilknyttet en VM instans af gangen. En volume have en størrelse på mellem 1GB og 1 TB. CloudWatch giver metrikker om EBS volume, som f.eks. forbrug, båndbredde og latency. Amazon Simple Storage Service (S3) [73] service tillader at gemme data i objekter af mellem 1 byte og 5 TB. Objekterne lagres i buckets og kan er tilgængelige vha. unik tildelt key. Objekter kan være private eller offentlige og rettigheder kan tildeles brugere. Data gemmes synkront til flere datacentrer. Amazon Relational Database (RDS) [74] service tilbyder en relational database baseret på MySQL. Der udføres automatisk backup af databasen og opdatering af database software. Størrelsen af databasen kan monitoreres vha. CloudWatch og evt. skaleres i størrelse. RDS kan afvikles på VM af forskellige konfigurationer. Amazon Simple Queue Service (SQS) [75] service tillader applikationer i forskellige eller samme VM at kommunikere via beskeder vha. en beskeds kø. Beskeder på køen kan have en størrelse på 64KB af typen tekst. Beskeder bliver gemt på køen i op til 14 dage. Når en applikation behandler en besked på køen, så bliver den låst, således andre applikationer ikke kan læse den. Beskeds s køer kan deles med andre AWS accounts eller anonymt og begrænses til specifikke IP adresser og tidspunkt af dagen. Alle beskeder gemmes på flere maskiner og datacentrer. Understøttende services I det følgende gennemgås kort yderligere services, som applikationer kan anvende til monitorering, styring, kommunikation, bruger authenticaton, forretning og business intelligence. Amazon CloudFront [75] service er en Content Delivery Service (CDN), som tillader at bringe data geografisk tættere på brugeren og levere data fra cache. Amazon Web Services Import / Export [76] service tillader at flytte data til eller fra S3 vha. storage device, f.eks. en USB forbundet hardisk uden om internettet. Amazon Simple Notification Service (SNS) [77] service tillader at notificere brugere om en specifik hændelse vha. eller HTTP/HTTPS, Amazon Web Services (AWS) Management Console [78] service tillader at styre AWS f.eks. stoppe og starte VM instanser eller oprette EBS volumes. Amazon Service Health Dashboard [79] service viser opdateringer drift tilstanden for de enkelte services fordelt på geografiske lokationer. Amazon CloudWatch [80] service leverer metrikker for de forskellige Side 47 af 159

48 services, f.eks. EC2 og S3 med en opdatering ned til et minut eller hvert 5 minut, hvis gratis service vælges. Autoscaling service benytter også CloudWatch til at definere politikker for op- og nedskalering af VM instanser. Amazon Mechanical Truk [81] service, også kaldet Crowdsouring eller Human as service (HaaS), kan anvendes af organisationer til at udbyde et stykke arbejde, som skal udføres og dermed opfylde forretnings mål. Et virtuelt community eller markedsplads af mennesker er til rådighed for at udføre arbejde. Det ønskede arbejde skal beskrives med en ønsket pris og resultat og eventuelle påkrævede kvalifikationer. Amazon Route 53 [82] service er en Domain Name System (DNS) service. Amazon Virtual Private Cloud (VPC) [83] service tillader at integrere en virksomheds eksisterende infrastruktur med AWS cloud vha. Virtual Private Network (VPN). På nuværeden tidspunkt understøttes integration af EC2. Dette muliggør det for en virksomhed at oprette en virtual private cloud. Amazon Fulfillment Web Service (FWS) [84] service er en produkt ordrer service, som tillader forhandlere at sende instruktioner til Amazon om at udfører ordrer på deres vegne. Amazon Flexible Payments Service (FPS) [85] service er en betalingsservice, som anvender Amazons betalingsinfrastruktur til at afregne med Amazon brugere for køb af produkter eller services. Amazon DevPay [86] service er en betalings service, som kan anvendes til at afregne forbrug og sende regning til brugere af applikationer, som afvikles i AWS. Alexa Web Information Service [87] service udbyder data om internet trafik herunder statistik for web sites og sites der henviser hertil. Alexa Top Sites [88] service tilbyder information om ranking af web sites og statistik. Amazon Identity and Access Management (IAM) [89] service tilbyder andre applikationer at håndtere brugere og deres rettigheder i AWS. Evaluering Amazon EC2 og de øvrige web services understøtter flere af autonomic computing aspekterne, afsnit 5.2. Element: krav KO.1, KO.2 Selvkonfiguration Den enkelte service skal foretage konfiguration af service afhængigheder uden anden støtte fra platformen. Selvoptimering Side 48 af 159

49 Det er mulig at kombinere auto scaling med en load balancer, således, at information om svar tiden for de enkelte virtuelle maskiner tilknyttet load balancer kan bestemme om yderligere virtuelle maskiner skal instansers. Selvhealing Instanser der afvikler applikationen, erstattes hvis de bestemmes til at være i en ikke tilladt tilstand. Selvbeskyttelse Hver virtuel maskine er beskyttet med et firewall lignende koncept, som begrænser forbindelser til specifik protokol typer og adresser. Services kan individuelt konfigureres med en sikkerhed politisk, som beskriver hvilke andre services har adgang hertil. Relationer krav KO.3-7 Der er ikke mulighed for service discovery og dermed f.eks. automatisk at foretage en omkonfigurering af en service sammensætning. Politikker krav KO.8-18 Brugeren har mulighed for at beskrive vha. politikker systemets opførsel i givne situationer f.eks., når CPU belastningen for en virtuel maskine overskrider en bestemt grænseværdi. EC2 og Auto scaling services kan bestemme om tilstanden for en virtuel maskine kræver, at denne skal erstattes med ny virtuel maskine og udføre aktiviteten. Interfaces krav KI.1-17 Det er muligt for services at forespørge tilstanden af en given service eller lifecycle model. Der er mulighed for indsamling af log information for den enkelte instans. System KS.1-5 Der tilbydes sentitel service vha. EC2 service, således, at services kan forespørge service tilstanden af andre services. Der tilbydes ikke yderligere services, som understøtter system service sammensætning herunder f.eks. service registry. Amazon giver brugeren videns deling i form af dokumentation til hele web services platformen herunder API, developer guides og referencer og andet. Brugeren kan desuden kommunikere med andre brugere og Amazon vha. fora og communities for de forskellige services. Brugeren kan også foreslå nye egenskaber for web services, oprette fejlrapporter eller følge op på status af kendte fejl. Udviklingsmiljøet for web services kan baseres på flere teknologier herunder Java, PHP, Ruby og andre teknologier, der understøtter en web services programmeringsmodel. Amazon leverer software udviklingsværktøjer til flere teknologier også til mobile enheder. Applikationerne, der afvikles i de virtuelle maskiner, kræver et runtime miljø, som kan installeres specifikt til formålet eller vha. et eksisterende virtuel maskine image. Side 49 af 159

50 Amazon vedligeholder software til SDK og services med en månedlig og kvartalslig frekvens. Amazon har datacentrer opdelt i 4 regioner: 2 i USA, 1 i Europa (Irland) og 1 i Asien (Singapore). Hver af disse regioner er yderligere opdelt i zoner for hver region. Amazon giver mulighed for valg af mange forskellige virtuelle maskine konfigurationer af computer og lager ressource kapacitet. Forskellige prisafregnings modeller kan vælges, som passer med et givent behov. Der kan vælges at afregne forbrug på time basis eller abonnere på ressourcer over en fast periode. Sidst kan der bydes på ledige ressourcer. En ressource købes, når det afgivne bud matcher eller overstige ressources nuværende værdi. Når ressourcens markeds værdi overstiger værdien af det afgivne bud frigives den igen. Side 50 af 159

51 7.1.5 Google App Engine Indledning Google App Engine giver brugeren mulighed for at afvikle applikationer i Googles infrastruktur, som også anvendes til Google andre services [104]. Applikationen understøttes med forskellige services i infrastrukturen herunder lagrings ressourcer, beskeds ressourcer, adgangskontrol og andet. Ressourcer bliver automatisk tildelt applikationen efter behov. Platform App Engine udbyder er et miljø, hvori applikationer kan afvikles. App Engine understøtter runtime miljøet til Java og Python. Applikationerne afgrænses til kun at udføre specifikke operationer, således at det sikres at de afvikles isoleret fra hinanden på platformen. Dette betyder f.eks., at applikationen ikke kan skrive til filsystem i runtime miljøet den afvikles i. Derimod kan der læses filer, som er uploaded sammen med applikationen. Applikationer udvikles og testes i det lokale udviklingsmiljø og udrulles herefter til App Engine ved upload af en samlet web application archive (WAR) fil. Anvendelsesdomæne Google App Engine beskrives ikke til at blive anvendt i specifikke anvendelses domæner, men App Engine afvikler applikationer efter Java Servlet og JavaServer Pages [104] og er derfor målrettet web applikationer. Licensmodel Alle App Engine services reguleres af kvoter og begrænsninger. En kvote beskrives med en metrik f.eks. antal beskeder en applikation kan sende til en given pris. Der beskrives 2 typer af kvoter: billable og fixed. Billable er kvoten på en applikation for en given service, som man giver som et budget. Forbruget af service kan ikke overstige denne værdi. Forbruget afregnes dagligt og nulstilles herefter undtagen for storage service. Der afregnes kun for det faktiske forbrug og det som overstiger den gratis service sats. Fixed kvoter er grænser på anvendelse af services sat af App Engine for at sikre, at applikationer ikke påvirker hinanden. Dette kunne f.eks. være maksimal antal beskeder sendt, fuldstændig liste findes i [135]. Tabel 11 og Tabel 12 viser forbrugsprisen for App Engine. Den alternative pris er for en always on instans, som afregnes til $0.30 pr. dag oveni timeforbruget. Instans type Ikke oplyst CPU Hukommelse Instans lager I/O ydelse kategori Ikke Ikke oplyst oplyst Størrelse ikke oplyst. Der afregnes $0.15 / GB pr. md. Pris pr. time Ikke oplyst $0.10 / $ Tabel 11: App Engine forbrugspriser [124], Side 51 af 159

52 Region Ud af datacenter pris Ind til datacenter pris Ikke oplyst $0.12 / GB $0.10 / GB Tabel 12: Dataoverførselspriser mellem forbruger og datacenter [124]. Google tilbyder derudover en prismodel til forretningen med separate priser og service level agreement (SLA) [125, 126], Standarder App Engine services beskrives vha. Java APIs og Python APIs [103], Styringsmyndighed Google App Engine styre af Google incorporated. Vedligeholdelse App Engine understøttes med udviklingsværktøjer til Java og Python, kaldet hhv. Java og Python software development kit (SDK). Derudover understøttes med Java med plugin til Eclipse IDE, således udvikling, test og udrulning integreres et i miljø. Tabel 11 viser versioner af Java SDK. Version Dato Beskrivelse December Oktober Generel opdatering August Generel opdatering August Understøttelse af multitenancy i datastore. Generel 2010 opdatering June 2010 Understøttelse af begrænsning på Task Queue. Generel opdatering Maj 2010 Understøttelse af klient data bulkloader. Generel opdatering April 2010 Understøttelse af nye system properties. Generel opdatering March 2010 Understøttelse af nyt Blobstore API. Generel opdatering Februar Generel opdatering December Understøttelse af nyt Blobstore API. Generel opdatering December Understøttelse JAXB. Generel opdatering. Understøttelse af always on instanser. Generel opdatering Oktober Understøttelse af indkomne beskeder. Generel 2009 opdatering September Juli 2009 General opdatering herunder memcache og cron Maj 2009 Første version. Understøttelse af validering af XML konfigurations filer for App Engine. Tabel 13: App Engine Java SDK versioner [128, 129]. Understøttelse af afsending af XMPP beskeder. Generel opdatering. Side 52 af 159

53 I alt er der frigivet 15 versioner af Java SDK, den seneste i december 2010 og den første i maj Det er fortrinsvis frigivelser på månedsbasis. Derudover arbejde Google med en roadmap for App Engine baseret på issues og bruger ønsker. Denne er vist i Tabel 14. Version Dato Beskrivelse Ikke oplyst Ikke oplyst Ikke oplyst Ikke oplyst Ikke oplyst Ikke oplyst Ikke oplyst Indenfor 6 md. Indenfor 6 md. Indenfor 6 md. Indenfor 6 md. Indenfor 6 md. Indenfor 6 md. Indenfor 6 md. SSL for third-party domains Background servers capable of running for longer than 30s Ability to select different availability vs. latency options for Datastore Support for running MapReduce jobs across App Engine datasets Bulk Datastore Import and Export tool Improved monitoring and alerting of application serving Programatic Blob creation in Blobstore Tabel 14: App Engine roadmap [127]. Der er mulighed for at følge App Engine services status på App Engine System Status [130] også i et historisk perspektiv. Google angiver ikke service level agreements for de enkelte services, hvis dette ønskes skal App Engine for Business [125, 126] anvendes i stedet. Det er ikke muligt at få information om eller bestemme, hvor applikationen geografisk afvikles på Google datacentrer. Instanser der afvikler en given applikation kan være på flere forskellige datacentrer. Google opfylder Safe Harbor principperne, men kan have problemer med lovgivning om personlig datasikkerhed i Europa, da brugeren ikke kan bestemme, hvor data er placeret geografisk. Brugerunderstøttelse App Engine støtter brugeren med dokumentation af forskellige aspekter af platformen herunder introduktion, detalje beskrivelse af services og et interaktivt miljø til afklaring af eventuelle spørgsmål. Det er også muligt at sende forespørgsler om nye egenskaber og rapportere fejl i produktet. Nedenfor er listet App Engine bruger støtte muligheder. - Issue tracker - Getting started guides - Developer guide - Tutorials - Service beskrivelser herunder API - Eksempler Side 53 af 159

54 - How-to instruktioner - Artikler - FAQ - Community med diskussions fora og mailing lists Værktøjsunderstøttelse Der findes App Engine SDK til Java og Python. Derudover findes understøttelse til IDE Eclipse for integration af udvikling, test og udrulning af applikation. Alternativt kan shell værktøjer anvendes til de samme aktiviteter. Arkitektur Google App Engine er en cloud teknologi, som tillader web applikationer at blive afviklet på Googles infrastruktur [103, 104]. Applikationer bliver afviklet i en virtual machine af process virtual machine typen Figur 23. Figur 23: App Engine arkitektur [105]. App Engine består af 3 komponenter: Runtime App Engine afvikler applikationer i, hvad der beskrives som instanser og er computing enheden, som anvendes til at udvide ressourcer til applikationen [136]. Instanser består af runtime miljø, App Engine API, applikations kode og hukommelse. Hver instans er isoleret fra hinanden vha. et sikkerhedslag. En applikation kan på et givent tidspunkt blive afviklet på en eller flere instanser afhængig af belastning. App Engine tildeler en applikation flere instanser efter, hvor mange forespørgsler, der findes til hver instans kø. Når køen er blevet kortere stoppes instanserne igen. Hvis en applikation ikke er aktiv stoppes tilknyttede instanser. Det er muligt at reservere instanser til en Side 54 af 159

55 applikation, således, at der ikke skal ventes på, at en instans starter en applikation ved den første forespørgsel. App Engine understøtter runtime miljøer i Java og Python. Java runtime kan afvikle Java Servlets og Java applikationer. Python runtime indeholder Python fortolker og standard liberary. App Engine beskrives med følgende egenskaber: - Persistent storage med queues, sorting og transaktioner - Automatisk skalering og load balancing - APIer med mulighed for at authenticate brugere og sende s vha. Google Accounts service - Mulighed for at udvikle i et lokalt udviklingsmiljø, som simulerer App Engine - Task queues til at udføre aktiviteter asynkront for den modtagne web forespørgsel - Planlagte tasks som udfører hændelser på specifikke tidspunkter og intervaller Applikationer afvikles i, hvad der kaldes en sandbox, hvor der er begrænset mulighed for tilgang til det underliggende operativ system- Applikationer bliver hermed isoleret i et miljø uafhængig af hardware, operativ system og fysisk lokation af server. Dette betyder, at en applikation skal anvende App Engine services for at oprette internet forbindelser (URL fetch service), skrive og læse fra filsystem (datastore service). Endelige afvikles applikationen kun på en web forespørgsel (med svar indenfor 30 sekunder), en queued task eller planlagt task og der kan ikke oprettes en ny proces i behandlingen af web forespørgsel. Dette gør det muligt for App Engine at distribuere web forespørgsler til applikationen over flere servere og stoppe og starte disse for at i møde gå forskellige situationer. Ti Java applikationer tilbydes web udviklingsværktøjer og standard APIer. Applikationen interagerer med miljøet vha. Java Servlet og JavaServer Pages. Java applikationer interagerer med App Engine services vha. Java APIer. App Engine Java SDK indeholder en implementation af Java Data Object (JDO) og Java Persistence API (JPA) interfaces. Python applikationer tilbydes tilsvarende APIer til App Engine services og understøtter yderligere frameworks til web udvikling herunder Django og webapp. Datastore App Engine storage, Datastore, er en distribueret data storage service som indeholder en query engine og transaktioner. Datastore er ikke en relationel database, men er i stedet baseret på data objekter eller entiteter, som har tilknyttet egenskaber, properties. Datastore er desuden ikke skema baseret, Side 55 af 159

56 det er applikationen, som bestemmer datastrukturen. Dette muliggøres vha. Java JDO/JDA interfaces og Python Datastore interface. Datastore er transaktions baseret, hvor operationer samlet i en transaktion enten lykkedes eller fejler. Den nuværende implementation af Datastore benytter en master / slave model, hvor data kopiers asynkront. Kun et datacenter kan være master. Implementationen skal i fremtiden ændres til, hvad der kaldes high replication Datastore og baseres på Paxos algoritmn[109], hvilket muliggør, at data kopiers synkront til flere datacentrer simultant. Services I det følgende gennemgås kort services, som udbydes af Google App Engine. 1. Blobstore [110] En applikation kan anvende Blobstore service, når data objekter benyttes, som er større end Datastore kan håndtere. En Blob kan oprettes ved upload af en fil til Blobstore. Blobstore opretter herefter en Blob (op til 2GB) til filens indhold og returnerer en reference eller Blob key, som kan anvendes til senere download. 2. Users / Google Accounts [120] En applikation kan anvende App Engine Google Accounts integration til at authenticate en bruger. API kan også anvendes til at håndtere applikationens brugerrettigheder 3. Channel [111] Denne service opretter en forbindelse mellem applikationen og klienten af denne og tillader beskeder at blive sendt til klienten uden polling. 4. Images [112] Denne service muliggør manipulation af billeder herunder størrelse og rotation af billeder i formaterne JPEG og PNG. 5. Mail [113] Applikationer kan anvende denne service til at sende s. 6. Memcache [114] Dette er en hukommelses cache, som tilgås vha. et key/value sæt. Denne cache kan anvendes af flere instanser af applikationen. 7. Multitenancy [115] Tillader at opdele applikationen i namespaces, således data kan opdeles mellem forskellige klienter af denne. Multinancy, i denne sammenhæng, er en arkitektur som tillader en instans af en applikation at tilbyde services til mange klient organisationer (tenants). Side 56 af 159

57 8. Task Queues [117] Denne service muliggør afvikling af applikationen, som ikke er initieret af en web forespørgsel. Applikationen kan skrive opgaver til en kø til senere udførsel, mens en web forespørgsel behandles. 9. Scheduled Tasks [118] Denne service muliggør afvikling af applikationen, som ikke er initieret af en web forespørgsel. Opgaver kan planlægges til afvikling hver time eller dagligt og kaldes også cron jobs. 10. URL Fetch [119] Denne service anvendes af applikationen til at tilgå andre resurser på internettet herunder web service og data. 11. XMPP [120] Extensible Messaging and Presence Protocol [133] (RFC 3921) er en service, som tillader en applikation at sende og modtage beskeder fra XMPP services, som f.eks. Google Talk. 12. DoS [134] App Engine tilbyder en Denial of Service beskyttelse, som forhindrer IP adresser eller subnets i at foretage web forespørgsler til applikationen. Hermed forhindres applikationen kvoter også i at blive opbrugt. Evaluering App Engine opfylder dele af autonomic computing kravene, afsnit 5.2. Element: krav KO.1, KO.2 Selvkonfiguration Den enkelte service skal foretage konfiguration af service afhængigheder uden anden støtte fra platformen. Selvoptimering Belastes en applikation med mange forespørgsler startes flere instanser til afvikling af og aflastning af applikationen. Dette bestemmes ud fra størrelsen af forespørgsel køen for den enkelte service. Selvhealing Instanser der afvikler applikationen, erstattes hvis de bestemmes til at være i en ikke tilladt tilstand. Selvbeskyttelse App Engine tilbyder services til adgangskontrol og denial of service beskyttelse. Side 57 af 159

58 Relationer krav KO.3-7 Der er ikke mulighed for service discovery eller forhandling af bedst egnede services, således at en samling af applikations services kan omkonfigureres, hvis enkelte services f.eks. fejler Politikker krav KO.8-18 Det er ikke muligt for brugeren vha. politikker at bestemme, hvordan systemet skal opføre sig f.eks. givet en specifik CPU belastning. App Engine afgøre ud fra fastsatte grænseværdier om en applikation skal tildeles flere ressourcer eller instanser. Interfaces krav KI.1-17 Det er ikke muligt for services at forespørge tilstanden af en given service eller lifecycle model. Der er mulighed for indsamling af log information for den enkelte instans. System KS.1-5 App Engine tilbyder ikke yderligere services, som understøtter system service sammensætning herunder f.eks. service registry. Google støtter brugeren med dokumentation af platformen og udviklingsværktøjer og giver kanaler for interaktion i form af fora og mailing lister. Det er også muligt for brugeren af følge status på fejl i softwaren og anmode om ny funktionalitet. Udviklingsmiljøet er målrettet Java og Python. Google understøtter udvikling til disse runtime miljøer med SDKer. Google vedligeholder software med en månedlig og kvartalslig frekvens. Det er ikke muligt brugeren at bestemme, hvor en specifik applikation afvikles for at sikre mod fejl i et enkelt datacenter. Alle instanser af en given applikation kan i princippet afvikles på den samme lokation. App Engine giver mulighed for at fastsætte et forbrugsbudget, som ikke må overskrides for applikationen. Derudover anvendes en time baseret forbrugsmodel for computer og lagring ressourcer Heroku Indledning Heroku beskrives, som en service, der tillader udviklere at investere tiden i udvikling i stedet for styring og vedligeholdes af servere [137], [154]. Platform Heroku er en cloud service applikations platform baseret på teknologien Ruby [155] med integration til versionsstyring teknologien Git [156] for udrulning af applikationen. Applikationen udviklings i det lokale udviklingsmiljø og udrulles herefter til Heroku cloud applikation afviklingsmiljø. Heroku understøtter brugeren med en Ruby applikation (gem) [157]. Dette er en applikation, der kommunikere med en Heroku Side 58 af 159

59 REST baseret web service til bl.a. udvidelse af applikations ressourcer (Dynos og Workers), oprettelse af applikation og styring af applikationsmiljø. Heroku anvender Amazon AWS datacentrer til applikationsplatform [158],[161]. Anvendelsesdomæne Heroku beskriver ikke specifikke anvendelses domæner med målretter platformen til udvikling af web applikationer [154]. Licensmodel Heroku anvender ressource abstraktioner kalder hhv. Dyno [139] og Worker [143]. Dette er elementer i system arkitekturen, som brugerens applikation afvikles på. En Dyno behandler modtage forespørgsler, indenfor en så kort tidsperiode som mulig, og sender længerevarende opgave aktiviteter til Worker køer til behandling. Brugeren bestemmer antallet af Dynoer og Workers efter f.eks. belastning af applikationen. Applikationen kan bliver startet på flere Dynoer og Workers for derved at distribuere forespørgsler og belastning. Tabel 15 viser prismodellen for Dynoer og Workers. Der afregnes forbrug pr. time. En Dyno og Worker er tilknyttet 5MB database lagerressource. Brugeren skal betale derudover betale for lagerressourcer. Instans type Dyno CPU Hukommelse Instans lager I/O ydelse kategori Pris pr. time 4 Dynoer Ikke oplyst 5 MB database Ikke oplyst $ svarer til en / 20 GB tilkøb CPU mulig for $15 / core[140], md. som ikke er nærmere beskrevet. Worker Ikke oplyst Ikke oplyst 5 MB database / 20 GB tilkøb mulig for $15 / md. Ikke oplyst $0.05 Tabel 15: Heruko prismodel[151]. 1 Den første Dyno er gratis. Standarder Heroku anvender Ruby [156] i applikationsplatformen og beskriver interface til applikation management web service med REST. Styringsmyndighed Heroku styres af Heroku incorporated fra den 31. januar 2011 en underafdeling af Salesforce.com incorporated [153]. Vedligeholdelse Heroku understøtter brugeren med management applikation til styring af applikation herunder oprettelse, tilføjelse af ressourcer og genstart af applikation server i Heroku cloud. Heroku applikationen er baseret på Ruby Side 59 af 159

60 og kan hentes fra Ruby repositories eller fra Heroku udviklings repository [152]. Tabel 16 viser et udvalg af versioner af denne. Version Dato Beskrivelse Januar 2011 Generel opdatering Januar 2011 Generel opdatering Januar 2011 Generel opdatering December 2010 Generel opdatering December 2010 Generel opdatering December 2010 Generel opdatering December 2010 Generel opdatering December 2010 Generel opdatering December 2010 Generel opdatering November 2010 Generel opdatering 1.0 Juni 2009 Generel opdatering Maj 2009 Generel opdatering Maj 2009 Generel opdatering 0.9 Maj 2009 Generel opdatering 0.8 April 2009 Generel opdatering April 2009 Generel opdatering 0.7 April 2009 Generel opdatering Marts 2009 Generel opdatering 0.6 Marts 2009 Generel opdatering Februar 2009 Generel opdatering Januar 2009 Generel opdatering August 2008 Generel opdatering Tabel 16: Heroku API kommando line værktøj versioner [152] I alt er der frigivet 96 versioner af applikationen baseret på både ugentlige og månedlige frigivelses planer. Tabel 16 viser versioner frigivet fra den første frigivelse august 2008 version indtil version 1.0. Den seneste version frigivet i januar 2011 og 10 versioner herefter. Der er mulighed for at følge nuværende status på Heroku platformen [159]. Heroku giver ikke service level agreement, men benytter Amazon AWS [161] og er dermed tilknyttet politikker, som Amazon beskriver herunder sikkerhedshåndtering. Heroku beskriver ikke de geografiske placeringer for datacentrerne bruger applikationer bliver afviklet i og brugeren har ikke mulighed for at bestemme dette. Brugerunderstøttelse Brugeren understøttes med dokumentation af platformen herunder interface beskrivelser og anvendelses vejledninger: - Dokumentation (service management interface, addon services og applikation platform) - FAQ - Getting started og quick guides Side 60 af 159

61 - Eksempler Derudover er der mulighed for interaktive kanaler i form af f.eks. mailing lists: - Blog - Support ticket system - Mailing lists - IRC kanal Værktøjsunderstøttelse Hovedværktøjet brugeren understøttes med i udvikling af applikationen er en Ruby baseret applikations gem. Ruby miljøet sammen med Git versionsstyrings værktøjet skal være tilgængelige i udviklingsmiljøet. Heroku web services er tilgængelig vha. af Ruby gem applikationen og muliggør styring af Heroku cloud platformen, hvor applikationen afvikles. Arkitektur Heroku er en PaaS cloud computing teknologi [137],[138] baseret på Amazon AWS infrastruktur. Herokus arkitektur er vist på Figur 24. Figur 24: Heroku arkitektur [138]. Arkitekturen består af 6 komponenter, som her er kategoriseret i compute, storage og andre services. Compute Dyno Grid Applikationer afvikles i hvad der kaldes et Dyno grid [139], [140]. Hver slot i grid indeholder en dyno, som indeholder applikationens afviklingsmiljø og storage database. Der kan allokeres eller oprettes så mange dynos, som er nødvendigt. Applikationskoden der afvikles i en dyno kaldes en slug [144] og er en compiled Ruby baseret applikation. Dyno grid er spredt over flere servere i flere datacentrer. Antallet af dynos allokeret til hver server afhænger af belastningen af denne. Side 61 af 159

62 Dyno En dyno er en proces som afvikler Ruby applikation kode [139],[140]. Strukturen af en Dyno ses på Figur 25. Figur 25: Heroku Dyno struktur [140]. 4 dynoer svarer til en CPU core [140]. Dyno består af 7 lag inklusiv applikationen. Posix environment er baseret på et Debian Linux operativ system og er en konfiguration af applikation database. Ruby VM er baseret på open source teknologi fra MRI Ruby VM og har til ansvar at opstarte App Server. App Server er baseret på open source teknologi fra Thin. App Server har til ansvar at opstarte Rack booter applikationen. Rack er baseret på open source teknologi fra Rack [142]. Rack udbyder et web interface og forbinder web forespørgsler til en Ruby proces Middleware er ikke obligatorisk, men muliggør forbindelse til database og cache eller route specifikke URLs til flere applikationer i den samme proces. Framework er ikke obligatorisk, men kan f.eks. være baseret på Ruby on Rails, som kan interface med Rack. Delayed job workers Disse worker processer [143] tillader en applikation at udføre arbejde asynkront for en web forespørgsel ved at sende det til en kø, som senere behandles Delayed Job workers. Storage SQL database [145] er baseret på open source teknologi fra PostgreSQL. Heroku muliggør automatisk og manuel backup snapshots af applikation Side 62 af 159

63 database. Heroku tilbyder databaser baseret på Amazon RDS, MongoDB, CouchDB gennem Add-ons. Memory cache [138] er baseret på open source teknologi Memcached. Den kan f.eks. anvendes til at cache resultater af database forespørgsler. Andre services HTTP reverse proxy [138] er baseret på open source teknologi fra Nginx. Denne har til ansvar at håndtere HTTP behandling f.eks. SSL, gzip kompression, hvorefter der forbindes til HTTP cache. HTTP cache [141] er baseret på open source teknologi fra Varnish. Denne komponent har til ansvar at cache web forespørgsler og svare tilbage, hvis resultatet findes i cached. Findes svaret ikke i cache sendes forespørgsel videre. Routing Mesh [138] er baseret på specifik kode i Erlang. Routing Mesh har til ansvar at fordele forespørgsler mellem applikationens dynos baseret på viden om dyno belastning og tilstand og registrere de-registrere dynos. Heroku tilbyder yderligere services vha. et addons system [160] indenfor f.eks. lageressourcer og adgangssystemer. Evaluering Heroku opfylder dele af autonomic computing aspekterne, afsnit 5.2. Element: krav KO.1, KO.2 Selvkonfiguration Det er ikke muligt vha. service discovery at foretage en omkonfigurering af en service sammensætning. Selvoptimering Der foretages automatisk software opdatering af instanser som afvikler services. Selvhealing Forespørgsler sendes automatisk til instanser, som er i en tilstand til at behandle dem. Instanser som bestemmes til at være i en forkert tilstand erstattes. Applikationens afviklings miljøet opdateres automatisk, når påkrævet ændringer skal indføres. Selvbeskyttelse Heroku tilbyder ikke specifikke mekanismer eller services til selvbeskyttelse. Relationer krav KO.3-7 Der er ikke mulighed for service discovery eller forhandling af bedst egnede services, således at en samling af applikations services kan omkonfigureres, hvis enkelte services f.eks. fejler Side 63 af 159

64 Politikker krav KO.8-18 Brugeren kan ikke vha. politikker bestemme, systemets opførsel f.eks. i en situation med høj CPU belastning. Brugeren har til ansvar at bestemme de påkrævede ressourcer til applikationen. Interfaces krav KI.1-17 Det er ikke muligt for services at forespørge tilstanden af en given service eller lifecycle model. Der er mulighed for indsamling af log information for den enkelte instans. System KS.1-5 Heroku tilbyder ikke yderligere services, som understøtter system service sammensætning herunder f.eks. service registry. Heroku tilbyder brugeren information i form af platform dokumentation. Der er desuden mulighed for interaktion med brugergrupper vha. mailing lister. Fejl kan rapporteres i fejlrapporteringssystem. Heroku er baseret på Ruby teknologien og leverer værktøjer og understøttelse til versionskontrol af applikation software og udrulning til Heroku cloud service. Heroku vedligeholder software værktøj på en ugentlig og månedlig frigivelsesplan. Det er ikke muligt for brugeren at bestemme, hvilken geografisk placering vælges for datacentrer, som afvikler applikation. Der udbydes en forenklet platforms model, hvor brugeren kan bestemme antallet af virtuelle maskine til afvikling af applikationen, men ikke specifikation af størrelse på ressourcer f.eks. hukommelse. Forbrug afregnes på timebasis og dette er den eneste model brugeren har mulighed for at vælge. Heroku platformen afvikles på Amazon AWS cloud services og afhænger derfor af politikker bestemt af Amazon, f.eks. datasikkerhed og service level agreements Joyent Indledning Joyent leverer forskellige cloud teknologier i form af SmartDataCenter[166] en datacenter teknologi målrettet service providers, SmartMachines[164], som er virtuelle maskiner i stand til at skalere vertikal ved en burst teknologi og SmartPlatform[163] et applikation afviklingsmiljø baseret på JavaScript Server tekonologi. Side 64 af 159

65 Platform Joyents public cloud services består af SmartMachines og SmartPlatform. SmartMachines kan konfigureres med forskellig software eller appliances herunder f.eks. Java og lagringsressource teknologier[172]. Brugeren kan vælge forskellige SmartMachines efter behov. SmartPlatform er et beta produkt fra Joyent og kan afprøves gratis i udrulningsperioden. Software er open source og kan afvikles på andre platforme. Begge teknologier afvikles i Joyent SmartDataCenter. Anvendelsesdomæne Joyent beskriver anvendelses domænet, som værende i miljøer, hvor applikationer hurtigt skal skalerer vertikalt eller horisontalt for at behandle uventede trafik krav[162]. Licensmodel Der betales for ressourcer for 1 måned af gangen. Tabel 17 er omregnet til timepris vha. Joyent angivet dagspris. Den første pris angiver timepris og den anden månedspris. Instans type CPU Hukommelse Instans lager I/O ydelse kategori Pris pr. time 256 MB 1/16 CPU 256 MB 5 GB Ikke opgivet $0.035 / $25 1 GB 1/4 CPU 1 GB 15 GB Ikke opgivet $0.174 / $125 2 GB 1/2 CPU 2 GB 25 GB Ikke opgivet $0.345 / $250 4 GB 1 CPU 4 GB 50 GB Ikke opgivet $0.694 / $500 8 GB 2 CPU 8 GB 100 GB Ikke opgivet $1.389 / $1, GB 4CPU 16 GB 200 GB Ikke opgivet $2.777 / $2, GB 8 CPU 32 GB 200 GB Ikke opgivet $5.555 / $4,000 Tabel 17: Joyent SmartOS Smart Machines prismodel[170]. Joyent tilbyder desuden også forskellige konfigurationer af SmartOS herunder MySQL, PHP, Riak og ZEUS. Disse konfigurationer har en mindre pris difference i forhold til standard SmartMachine. CPU er ikke specificeret yderligere af Joyent end anvist i [173]. Joyent vertikal skalerings teknologi muliggør SmartMachines i korte perioder at burst optil 8 CPUer. Derudover kan SmartMachiens og afvikle virtuelle maskiner af type Windows og Linux. Disse findes der en separat prismodel for. Udover forbrug for computer ressourcer afregnes der også på datatrafik. Priserne for dette ses i Tabel 18. Region Ud af datacenter pris Ind til datacenter pris Ikke oplyst, men antagelig USA 10 TB / md er gratis herefter tillægges $0.15 per GB 10 TB / md er gratis herefter tillægges $0.15 per GB Tabel 18: Dataoverførselspriser mellem forbruger og datacenter fordelt på regioner [170]. Side 65 af 159

66 Standarder SmartMachines kan afvikle applikationsteknologier og miljøer for Unix og Linux herunder f.eks. Java. Dette kræver blot at de er ported til OpenSolaris. Teknologier specifikke for Windows kræver at SmartMachine afvikler en Windows virtuel maskine. Styringsmyndighed SmartMachine, SmartPlatform og SmartDataCenter teknologierne styres af Joyent incorporated. Vedligeholdelse Joyent leverer ikke værktøjet eller software til Joyent teknologierne. Joyent SmartPlatform er endnu i beta og der er ikke frigivet officiel software hertil endnu. SmartMachines, som afvikles i SmartDataCenter opdateres, når der er behov for dette. Joyent giver service level agreement på levering af cloud service til brugeren [175]. Det er ikke muligt for brugeren at vælge den geografiske placering af datacenter hvori applikation afvikles. Joyent følger Safe Harbor principperne for datasikkerhed[176] og undergår service audit i form af SAS70 Type II [173], en audit standard for service organisationer. Det er ikke muligt at følge Joyent service status i det offentlige domæne. Brugerunderstøttelse Brugeren understøttes med dokumentation i form af. - Wiki - Eksempler - Whitepapers - Blog Brugeren kan interagere vha. følgende kanaler: - Forums - Webinars - Communities Side 66 af 159

67 Værktøjsunderstøttelse Joyent leverer ikke værktøjet eller software til Joyent teknologierne. Arkitektur Joyent arkitektur består af 3 komponenter[162], [167]. SmartMachine Joyent har defineret en SmartMachine [162], [164],[165],[167] til at i møde gå emner for system virtual machines herunder vedligeholdelse af OS, vertikal skalering og opstartstid for virtual machine. Joyent har sammenlagt OS og virtualiserings software og dermed dannet en process virtual machine eller virtual OS (Joyent SmartOS), hvori en applikation kan afvikles, som ses på Figur 26. Figur 26: Joyent SmartMachine [166]. Hermed har applikationen adgang til en pool af resourser vha. SmartOS i stedet for afgrænsede resurser for en system virtual machine. SmartOS er baseret på Joyent Unix fra OpenSolaries og tilbyder følgende egenskaber for SmartMachine: - Ressource bursting: SmartMachines kan tilgå udvidet resurser herunder CPU, hukommelse og netværk, når situationen kræver det. - Flexible configuration: SmartMachines kan bestilles med forskellige konfigurationer f.eks. med udviklingsplatforme PHP, Java, Ruby og databaser f.eks. MySQL og load balancers. Desuden kan SmartOS afvikle Xen[178] virtual machines med understøttelse for forskellige varianter af Windows og Linux operativ systemer. - Enhanced application performance: Der udføres cache på alle disk operationer. Hukommelse og CPU, som ikke anvendes til applikationen benyttes til dette. - Integrated security: Operativ system kernel kan ikke manipuleres, da SmartOS isolerer hukommelse, CPU og netværk og blokerer Side 67 af 159

68 netværks konfiguration og netværks sniffing. Dermed er applikationer isoleret fra hinanden. SmartDataCenter Joyent SmatDataCenter [162],[166],[167] er en abstraktion af data centret, hvori f.eks. SmartMachines afvikles, Figur 27. Figur 27: Joyent SmartDataCenter arkitektur [166]. SmartDataCenter tillader styring af alle resurser i datacentret herunder: compute, storage og netværk. SmartDataCenter udbyder APIer, som muliggør konfiguration af netværk, fejl detektering, oprettelse og nedlukning af SmartMachines og f.eks. at flytte en proces fra en fysik maskine og starte den igen på en anden. Desuden understøtter SmartDataCenter virtualisering af netværk herunder: VLANs, load balancing, VPN og routing. SmartDataCenter skalerer resurser vha. en besked bus, message bus, baseret på protokollerne Advanced Message Queuing Protocol (AMQP) [179] og Extensible Messaging and Presence Protocol (XMPP)[180]. SmartDataCenter tillader administration vha. web service eller automatisering i software. Dette tillader monitorering af resurser i datacentret. Desuden beskrives følgende egenskaber: Flexible deployment: Der kan købes licenser til private, public og vituelle private implementeringer. Centralized management: Alle SmartMachines i datacentret kan styres af GUI applikation herunder allokering af resurser og OS software opdatering. Entensible, ressource-oriented architecture: Kunder kan tilføje eller fjerne resurser uden at dette har indvirkning på SmartDataCenter. Side 68 af 159

69 SmartPlatform. Joyent arkitekturen udbyder udover IaaS tilgangen også en PaaS tilgang i SmartPlatform [162],[163],[167] i en sammensætning, som kan ses på Figur 28. Figur 28: Joyent SmartPlatform arkitektur [166]. SmartPlatform udbyder et udviklingsmiljø baseret på JavaScript server teknologi, som afvikles på SmartMachines. SmartPlatform skalerer automatisk applikationens resurse behov vha. SmartDataCenter. SmartPlatform er open source og tillader dermed at blive afviklet i andre miljøer, som ikke er baseret op Joyent teknologi. Figur 29 viser et eksempel på, hvorledes en web applikation kan skalere vha. Joyent SmartMachines. Figur 29: Joyent arkitektur skalering [168]. Services Yderligere services kan tilkøbes eksisterende SmartMachines [170], listet nedenfor. Side 69 af 159

70 SmartMachine Additional Local Storage: Udvidelse af SmartMachine storage i antal GB. Additional IP Address: Udvidelse af IP version 4 adresser med en begrænsning på 1 IP adresse per. GB hukommelse. SSL Cert: SSL certificates kan tilkøbes. Additional Network Transfer: Ud over 1GB/sek. netværkshastighed indenfor SmartDataCenter og 10TB internet trafik, som hver SmartMachine leveres med kan der tilkøbes yderligere internet trafik. Smart DataCenter Network Storage: Ud over den lokale SmartMachine storage kan der tilkøbes netværks storage. CDN Integration: Der skal tilbyder Content Delivery Network service til cache af applikation storage geografisk tæt på applikationsklienten. Evaluering Joyent opfylder dele af autonomic computer aspekterne, afsnit 5.2. Element: krav KO.1, KO.2 Selvkonfiguration Det er ikke muligt vha. services discovery service at foretage en omkonfigurering af en service sammensætning. Selvoptimering Applikationer kan automatisk vertikalt skalere i korte perioder. Kræves der yderligere ressourcer skal brugeren bestille dette. Selvhealing Instanser overvåges og erstattes eller genstartes, hvis er i en forkert tilstand. Selvbeskyttelse Der er ikke oplyst mekanismer eller services, som kan give service selvbeskyttelse egenskaber. Relationer krav KO.3-7 Der er ikke mulighed for service discovery eller forhandling af bedst egnede services, således at en samling af applikations services kan omkonfigureres, hvis enkelte services f.eks. fejler Politikker krav KO.8-18 Brugeren kan ikke vha. politikker bestemme systemets opførsel. Interfaces krav KI.1-17 Det er ikke muligt for services at forespørge tilstanden af en given service eller lifecycle model. Der er ikke mulighed for indsamling af log information for den enkelte instans. Side 70 af 159

71 System KS.1-5 Joyent tilbyder ikke yderligere services, som understøtter system service sammensætning herunder f.eks. service registry. Joyent tilbyder brugeren dokumentation i form af wikis whitepapers og andet. Brugeren kan kommunikere med Joyent og andre brugere vha. forums, webinars og communities. Brugeren kan ikke bestemme, den geografiske placering af datacenter, hvori applikationen afvikles. Joyent tilbyder en månedlig abonnent prismodel. Joyent opfylder Safe Harbor principperne for datasikkerhed for data udvekslet mellem USA og Europa. Desuden udføres audits af organisationen herunder datacentrer. Joyent giver service level agreement på leverede cloud services Konklusion I det efterfølgende gennemgås resultaterne fra foranalysen af teknologi kandidaterne fordelt på analyse elementerne. Ud fra resultaterne foretages et valg af teknologi til eksperiment fasen. Valget foretages på en kvalitativ og kvantitativt vurdering af f.eks. brugerunderstøttelse og på f.eks. dækning af autonomic computing krav. Desuden vurderes også realisering af case til eksperiment samt forfatterens kendskab og erfaring med udviklingsteknologi for at begrænse udviklingstiden anvendt på case. Platform EC2 er IaaS og understøtter virtuelle maskiner baseret på forskellige operativ systemer med mulighed for konfiguration af forskellige runtime miljøer og applikationer. Azure er PaaS med mulighed for IaaS for Windows server virtuel maskine. Asure understøtter.net teknologi og har mulighed for konfiguration af andre runtime miljøet herunder Java. Heroku er PaaS baseret på Ruby teknologi. App Engine er PaaS baseret på Java og Python teknologi. Joyent er IaaS og understøtter forskellige operativ systemer med mulighed for konfiguration af forskellige runtime miljøer hovedsagelig baseret på GNU applikationer. Joyent benytter eget operativ system, SmartOS, som også anvendes til virtualisering af andre operativ system herunder Windows og Linux. Side 71 af 159

72 Licensmodel Teknologierne baseres på forskellige prismodeller. EC2 understøtter: forbrugsmodel (on demand), udbudsmodel (spot instances), hvor der bydes på den billigste ressource og abonnent model (reserved instans), hvor der betales et fast beløb for en periode, herefter time prisen reduceres for ressourcen. Azure understøtter: forbrugsmodel og abonnent model, hvor der betales et fast beløb for en periode, herefter time prisen reduceres for ressourcen. Heroku, App Engine og Joyent understøtter en forbrugsmodel. App Engine tilbyder yder kvoter for forbrug, således at det er muligt at sætte en begrænsning på forbrug af ressourcen. Tabel 19 viser en oversigt for, hvorledes prisen for ressourcen indenfor CPU, hukommelse og lager for de enkelte teknologier placeres. Den billigste ressource pris findes i E2, mens den dyreste findes i Joyent. Teknologi CPU Hukommelse Lager Azure EC App Engine 2 ikke oplyst ikke oplyst Heroku 4 ikke oplyst ikke oplyst Joyent Tabel 19: Sammenligning af placering for billigste ressource priser. Det skal bemærkes, at CPU ydelsen for de enkelte teknologier ikke kan direkte sammenlignes. Desuden skal det bemærkes, at EC2 og Joyent understøtter bust teknologi, således at flere kerner et til rådighed i korte perioder. Prisen for de varige antal kerner anvendes. Tabel 19 sammenligner prisen for antallet af fysiske eller virtuelle CPU kerner. Heroku oplyser, at 4 applikations instanser svarer til en CPU kerne dette er medregnet i prissammenligningen. Oveni denne priserne skal lægges pris for data trafik ud og ind af datacenter. Dette afregnes til mellem $ pr. GB afhængig af den geografisk placering af datacenteret. Joyent har gratis data trafik for de første 10 TB, herefter tillægges $0.15 pr. GB. Nedenfor i Figur 30, Figur 31 og Figur 32vises priser for teknologi ressourcer fordelt på instans CPU kerner, lagerplads og hukommelse. EC2 har en ikke-lineær funktion for pris og ressource element. Dette skyldes, at Amazon tilbyder instans konfiguration med forskellige hukommelse og lager konfigurationer for given antal CPU kerner. Side 72 af 159

73 Figur 30: Pris pr. time i dollars for CPU kerner for teknologierne. Heroku er omregnet til 4 applikations instanser svarende til en CPU kerne. Figur 31: Pris pr. time i dollars for instans lagerplads i MB for teknologierne. Side 73 af 159

74 Figur 32: Pris pr. time i dollars for instans hukommelse i MB for teknologierne. Standarder EC2 understøtter web services teknologier REST og SOAP til beskrivelse af infrastruktur services. Azure understøtter.net teknologi, web services teknologi REST for infrastruktur services og egne teknologier til f.eks. databaser vha. TDS. Heroku anvender Ruby til runtime miljø og applikationsudvikling. Derudover anvendes REST til applikations management service. App Engine anvender Java og Python til runtime miljø og applikationsudvikling. Joyent tilbyder ikke udviklingssoftware og har ingen infrastruktur services, som instanser kan tilgå. Vedligeholdelse EC2, Azure, Heroku og App Engine udfører vedligeholdelse af udviklingssoftware, service interfaces og instans software med daglig, månedlig og kvartal frigivelsesplaner. Joyent tilbyder interfaces og udviklingssoftware. EC2 og Azure har datacentrer i Europa. App Engine giver ikke bruger mulighed for valg af geografisk udrulning af applikation. Joyent har datacentrer i USA. Alle teknologier understøtter Safe Harbor principperne om håndtering persondata mellem USA og Europa. Alle teknologier beskriver service level agreement. Side 74 af 159

75 Alle teknologier undtagen Joyent giver mulighed for service status overblik. Brugerunderstøttelse Alle teknologier leverer dokumentation af service interfaces og udviklingssoftware samt guides. Desuden gives mulighed for bruger interaktion i form af fora og andre kanaler. Joyent leverer ikke udviklingssoftware eller yderligere services. Værktøjsunderstøttelse EC2, Azure, Heroku og App Engine leverer software udviklingsværktøj (SDK) til applikationsudvikling. Azure leverer udover.net også til Ruby, Java og PHP. EC2 leverer SDK til Java, PHP, Ruby,.NET og Python. EC2, Azure og App Engine understøtter Eclipse IDE integration, Azure også eget IDE vha. Visual Studio. Understøttelse af autonomic computing self managed arkitektur krav. EC2 opfylder delvis autonomic computing krav. I forhold til krav Relationer KO.3-7 og System KS.1-5 gives der ikke mulighed for service discovery for understøttelse af konfiguration af service sammensætning. Azure opfylder delvis autonomic computing krav. I forhold krav Politikker KO.8-18 er det ikke muligt vha. politikker at bestemme, hvordan systemet skal opfører sig i givne situationer f.eks. under CPU belastning. I forhold krav Interfaces krav KI.1-17 er der ikke mulighed for at forespørge tilstanden eller lifecycle model af en given service. Heroku opfylder delvis autonomic computing krav. I forhold til krav Element KO.1, KO.2 og Relationer KO. 3-7 og System KS.1-5 gives der ikke mulighed for service discovery for understøttelse af konfiguration af service sammensætning. Desuden findes der ikke mekanismer eller services for selvbeskyttelse i forhold til krav Element KO.1, KO.2. I forhold krav Politikker KO.8-18 er det ikke muligt vha. politikker at bestemme, hvordan systemet skal opfører sig i givne situationer f.eks. under CPU belastning. I forhold krav Interfaces krav KI.1-17 er der ikke mulighed for at forespørge tilstanden eller lifecycle model af en given service. App Engine opfylder delvis autonomic computing krav. I forhold til krav Element KO.1, KO.2 og Relationer KO. 3-7 og System KS.1-5 gives der ikke mulighed for service discovery for understøttelse af konfiguration af service sammensætning. I forhold krav Politikker KO.8-18 er det ikke muligt vha. politikker at bestemme, hvordan systemet skal opfører sig i givne situationer f.eks. under CPU belastning. I forhold krav Interfaces krav KI.1-17 er der ikke mulighed for at forespørge tilstanden eller lifecycle model af en given service. Joyent opfylder delvis autonomic computing krav. I forhold til krav Element KO.1, KO.2 og Relationer KO. 3-7 og System KS.1-5 gives der ikke mulighed for service discovery for understøttelse af konfiguration af service Side 75 af 159

76 sammensætning. I forhold krav Politikker KO.8-18 er det ikke muligt vha. politikker at bestemme, hvordan systemet skal opfører sig i givne situationer f.eks. under CPU belastning. I forhold krav Interfaces krav KI.1-17 er der ikke mulighed for at forespørge tilstanden eller lifecycle model af en given service. Teknologivalg Der vælges at fortsætte med teknologi kandidat Amazon AWS EC2. Denne har god understøttelse af dokumentation, blandt de bedste for understøttelse af cloud computing og self managed arkitektur krav samt værktøjsunderstøttelse for debug, service interface og udrulning af services. Desuden har den en meget fyldestgørende understøttelse af forskellige web services uden dog et service registry, som muliggør service discovery og service sammensætning. Forbrugsprisen er den laveste af teknologierne, hvilket reducerer omkostninger i udviklingsprocessen. Service findes i datacenter i Europa, således forbindelsen ikke bliver etableres til f.eks. USA med mulighed for forsinkelser på data trafik. Der findes SDK til Java, hvilket giver forfatteren mulighed for at anvende kendskab og erfaring til udvikling af case. EC2 er IaaS, hvilken i forhold til PaaS, betyder, at runtime miljø skal installeres og konfigureres i de virtuelle instanser. Side 76 af 159

77 7.2 EKSPERIMENT I dette afsnit anvendes den valgte teknologi i et eksperiment for at afklare og evaluerer denne for brugbarheden vha. usability kvalitetsattribut scenarier, som er beskrevet i afsnit 6.4. Brugbarheden af kandidaten evalueres ud fra usability kvalitetsattribut scenarier Bass [10]. De enkelte scenarier kan betragtes som faser, der selvstændigt konkluders inden den næste påbegyndes. Scenarierne bruges til strukturering af arbejdet i evalueringsperioden og dokumenterer samtidigt, hvordan evalueringen af kandidaten er foretaget. Konklusionerne på de enkelte scenarier skrives løbende under arbejdet. Scenarierne udføres i forbindelse med realiseringen af den definerede case. Som afslutning på evalueringen beskrives generelt om indtryk og erfaringer med udvikling med kandidaten Case beskrivelse Casen, der udvælges til eksperimentet, skal give mulighed for at udnytte kvaliteter, som en autonomic computing self managed arkitektur tilbyder. Kvalitetsattributter for en sådan arkitektur er bl.a. pålidelighed (reliability) og tilgængelighed (availability). Tidligere rapport [11] udarbejdet om et safety kritisk system for en kemisk fabrik [8,9] giver mulighed for at undersøge den valgte teknologi kandidats understøttelse for autonomic computing kvaliteter. Dette system havde krav sikkerhedskrav (safety) om pålidelighedskrav (reliability). I den resulterende arkitektur for systemet blev der anvendt forskellige taktikker for at sikre de nævnte kvaliteter. I eksperimentet skal afprøves, hvordan teknologi kandidaten understøtter et udvalg af taktikker. I det efterfølgende beskrives oplægget il opgaven og uddrag af opgave løsningen. Herefter afgrænses funktionalitet og kvalitetskrav, som eksperimentet skal behandle fra opgaven. Casen er baseret på systemet til monitorering og kontrol af en kemisk fabrik [8] konceptuelt illustreret i Figur 33. Side 77 af 159

78 Figur 33: Koncept system [8, 11]. Systemet kaldes CP09 efterfølgende. Den kemiske fremstillingsproces, som systemet skal styre og monitorere består af følgende aktiviteter. 2 væsker A og B skal blandes i en beholder, mens den opvarmes og er under tryk. Resultatet af processen er kaldes C. Denne proces foregår kontinuerligt, således tilføres væsker A og B til beholderen fortløbende og resultatet findes i C. For at styre og monitorer processen findes 2 tryk og temperatur sensorer hhv. Ps1 og Ps2 og Ts1 og Ts2, som måler tryk og temperatur i beholderen. Desuden består systemet af aktuatorer til at regulere fremstillingsprocessen baseret på tryk og temperatur målinger. Aktuatorerne består af et varmelegeme (H), pumper(pa og Pb) og udgangsventil Vo samt sikkerhedsventil Ve. Systemet har til ansvar at bibeholde et konstant højt tryk i beholderen ved at kontrollere strømmen til de 2 pumper Pa og Pb samt udgangsventil Vo. Når udgangsventilen lukkes opbygges trykket i beholderen og tilsvarende åbnes den falder trykket. Den rette temperatur for processen styres ved at tænde og slukke varmelegeme H. Hver sensor og aktuator håndteres af en hardware enhed, som forbindes via seriel protokol RS-232 til en computer. En computer kan være tilknyttet en enkelt sensor eller aktuator eller et set af dem. Desuden kommer hver sensor og actuator med et interface til at monitorere og kontrollere det med listet i Figur 34, Figur 35, Figur 36, Figur 37, Figur 38 og Figur 39. /** Responsibility: To control the heater */ public interface Heater { /** Turn heating coil on or off. on if true the heater is activated, if false is is * deactivated. Side 78 af 159

79 */ public void turnon(boolean on); } Figur 34: Varmelegeme interface [8]. /** Responsibility: To measure pressure upon request. */ public interface PressureSensor { /** Measure the pressure the pressure in Pascal (Newton per square meter) */ public int getreading(); } Figur 35: Tryk sensor interface[8]. /** Responsibility: To control the pump */ public interface Pump { /** Set the power of the pump. pct the percentage of full pump power that the pump should * run at. If the pressure on the output side is larger than on the * input side then fluid may run 'the wrong way' if the percentage * of full power is low. pct should always be in the range ; */ public void setpower(int pct); } Figur 36: Pumpe aktuator interface[8]. /** Responsibility: To measure temperature upon request. */ public interface TemperatureSensor { /** Measure the temperature the temperature in Celcius */ public int getreading(); } Figur 37: Temperatur sensor interface[8]. /** Responsibility: To control the emergency valve */ public interface ValveEmergency { /** This is a method than can only be invoked once, a reset of * the valve to close it must be made manually by operators of the * hardware. */ public void open(); } Figur 38: SIkkerhedsventil aktuator interface[8] /** Responsibility: To control the output valve */ public interface ValveOutput { /** Set the opening size of the output valve pct the percentage of fully open valve. pct should always * be in the range If pct == 0 then the valve is closed; * if pct == 100 then the valve is fully open. */ public void setopening(int pct); } Figur 39: Ventil aktuator interface[8]. Side 79 af 159

80 Kravene til CP09 systemet er listet i Tabel 20. Id Krav Kravs klasse KR- 1 For højt tryk eller for høj temperatur vil sprænge og ødelægge beholderen og væskerne heri vil fordampe i anlægges omgivelser og udgør en alvorlig risiko for menneskene i anlægget. Desuden vil en efterfølgende reparation, oprydning og afbrudt produktion være meget bekostelig for anlægget. I tilfælde af en nødsituation hvor tryk og temperatur opbygges vil en sikkerhedsventil åbne og føre væskerne til et sikkerhedskammer og hermed undgå Safety/business KR- 2 KR- 3 KR- 4 skader på mennesker og beholder. Nøjagtig kontrol af den kemiske proces er meget vigtig pga., at selv meget små afvigelser / fejl i temperatur og tryk vil resultere i, at output C vil blive af lav kvalitet, hvilket vil reducere prisen på produktet betragtelig og dermed fortjeneste for anlægget. Det er forudset, at systemet vil indeholde en applikation kaldet CP09-control. Ansvar: kontrollere den kemiske proces for at maksimere sikkerhed (safety) og fortjeneste. Algoritmen, som beregner den rette kontrol af pumpestyrke, varme og udgangsventil åbning, er meget kompleks og involverer at løse hydro-dynamiske ligninger i real-tid. Det er forudset, at systemet vil indeholde en applikation kaldet CP09-monitor Ansvar: At vise et grafisk billede og visualisere systemet i kontrolrummet for anlægget, således af beholderen vises med sensor og aktuator data og alarmere operatørerne i tilfælde af detekterede risici i systemet. Business Funktionalitet / komponent Funktionalitet / komponent Tabel 20: CP09 arkitektur funktionelle krav, sikkerhedskrav og forretningskrav [8]. CP09-control er en closed loop proces kontrol med en pseudo kode algoritme som vist i Figur 40. do every 1 second { // Measure condition in vessel temp1 := Ts1.getReading(); temp2 := Ts2.getReading(); pres1 := Ps1.getReading(); pres2 := Ps2.getReading(); // Interpolate "actual" condition temp := propert(temp1, temp2); pres := properp(pres1, pres2); // calculate the response to get the optimal // chemical reaction and production (pumppowera, pumppowerb, heat, outputvalveopening) := controlalgorithm(temp,pres); // and actuate pumps, heating, and valve PA.setPower(pumppowerA); PB.setPower(pumppowerB); H.turnOn(heat); Vo.setOpening(outputvalveopening); } Figur 40: CP09-Control pseudo kode [8]. CP09-control løser hydro-dynamiske ligninger for beholderens tryk og temperatur hvert sekund og fortager reguleringer af processen ved at aktivere aktuatorer. Side 80 af 159

81 Der er udført en foreløbig risiko analyse af systemet [8] vha. risikoanalyse proces [3] og de mest alvorlige risici identificeret er for højt og for lavt tryk i beholderen, da disse er influeret af andre fejl f.eks. forkerte sensor værdier. For systemet er ricisi for højt og for lavt tryk i beholderen tilladelige klassificeret til som i Tabel 21. Identificeret risici Beholder tryk for højt Beholder tryk for lavt Risiko klasse Risiko alvorlighed Konsekvenser Tilladelighed Service failure Høj Safety Intolerable Service failure Medium Business ALARP Tabel 21: Klassificering af ricisi for CP09 [11]. Ud fra identificerede risici er der udført en root cause analysis [3] og udarbejdet et root cause træ. De enkelte root causes er behandlet med availability taktikker for at bringe dem ned på det tilladelige niveau. Dette er vist i Tabel 22. Id Root cause Availability kvalitets Taktikker og løsning Attribut / fault type RC-1 Sensorfejl Fault recovery - repair, Fault detection RC-2 Sensor algoritmefejl Fault recovery - repair RC-3 Kontrol Fault recovery - algoritmefejl repair RC-4 Manglende Fault detection vedligeholdelse RC-5 Defekt hardware Fault recovery - repair, Fault detection RC-6 Strømsvigt Fault recovery - repair Redundans og Ping / echo Redundans og voting Redundans og Passive redundancy, voting Vedligeholdelsesplan, software notifikation Redundans, Ping / echo strategi, heart beat Redundans, UPS tilknyttes de enkelte systemer Tabel 22: Root casue analyse resultater og kvalitets attribut availability taktikker [11]. Givet denne analyse er der designet en arkitektur, som vist i på Figur 41. Afgrænsning I tidligere rapport [29] er disse krav blevet behandlet i en risk-analysis, hvor root failure causes er blevet identificeret. For at imødekomme de identificerede fejl kilder er der anvendt forskellige arkitektur availability taktikker, hvilket har resulteret i arkitektur deployment view på Figur 41. Side 81 af 159

82 Figur 41: Safety kritisk deployment view [29], de markerede knuder realiseres i case. Casen afgrænses til komponenterne: - Kontrol - Monitor - Sensor par (temperatur og tryk) - Aktuator Dermed afgrænses casen til funktionelt at omhandle, at kontrol komponent periodisk indlæser sensor værdier, som kan følges vha. monitor komponent. Ved for temperatur værdier over 30 grader celsious sendes en besked til varmelegeme aktuator om at reducere temperaturen. Tryk behandles ikke i casen ud over en visuel repræsentation i vha. monitor komponenten. Koncept Det kan dermed undersøges, hvorledes availability taktikkerne anvendt i det oprindelige system til at imødekomme root cause failures kan realiseres i det autonome system. Figur 42 viser konceptuelt, hvorledes det autonome system vha. aspekterne self-healing og self-configuration kan realiseres vha. kandidaten udvalgt. Side 82 af 159

83 Figur 42: Afgrænset autonome system koncept af CP09. Systemet har angivet vha, en politik, at hvis en komponent i systemet belastes med mere end 80 % af CPU kapaciteten, så skal der startes en ny virtuel maskine instans for den givne komponent type. Dette er på Figur 42 vist med operationerne: 1. Politik brudt (CPU belastning uden for grænseværdi) 2. En ny instans af komponenten startes Disse aspekter af self management skal den valgte kandidat evalueres ud fra. Side 83 af 159

84 7.3 EVALUERING I det følgende evalueres AWS i definerede usability kvalitetsscenarier Usability scenarie 1: Opsætning af udviklingsmiljø Dette usability scenarie vedrører tilegnelse af kendskab til AWS cloud udviklingsplatformen og konfiguration af udviklingsmiljø, således alle afhængigheder er på plads og de grundlæggende services kan starte. Eclipse anvendes som udviklingsværktøj (Integrated Developer Environment - IDE) og dette skal konfigureres med alle afhængigheder. Når en teknologi specifikt interface kan realiseres uden anmærkninger, så er opgaven løst. Kilde Stimulus Artefakt(er) Miljø Respons Måling Forfatteren af rapport og udvikleren af case Tilegne grundlæggende kendskab til artefakter og strukturer. Dokumentation og eksempler. Linux / Windows platform. Artefakter giver det nødvendige struktureret overblik. Vurderingen sker ud fra forbrugt tid målt i dage og forventes afsluttet inden 3 dage (21 timer). Proces steps Scenariet er baseret på en proces af 8 steps, som behandler oprettelse og aktivering af AWS account, oprettelse af services sikkerhedscredentials og konfiguration af udviklingsmiljø. Disse steps er listet nedenfor. 1. Account oprettelse 2. Services aktiverering 3. Oprettelse af sikkerheds credentials 4. Oprettelse af EC2 instans sikkerhedsgruppe 5. Installation af Java SDK 6. Konfiguration af API service kommando værktøjer 7. Installation af AWS Java Eclipse Toolkit 8. Oprettelse af projekt Account oprettelse For at benytte AWS skal man oprettes som bruger af systemet. Dette foregår vha. AWS account web service [181]. Figur 43 viser menu interfacet Sign up for free Amazon Web Services Account eller Create an AWS account, som benyttes i account oprettelses processen. Side 84 af 159

85 Figur 43: Oprettelse af AWS account [181]. Aktivering af oprettelse af ny bruger acount vises på Figur 44, her angives adresse på brugeren. Figur 44: AWS account oprettelse ny bruger af service[181]. Figur 45 viser den efterfølgende proces for registrering af bruger account. Dette er en 3 steps proces, hvor brugeren giver account information bl.a. navn, adresse og betalingskort konto information tilknyttet brugeren. Denne information benyttes til automatisk at afregne brugerens forbrug af AWS. Side 85 af 159

86 Figur 45: AWS account oprettelse processen [181]. Det sidste step i registreringsprocessen er en bruger oprettelses bekræftelse, som vises på Figur 46. Denne sendes til brugerens adresse. Dette indikerer, at brugerens account er aktiv og AWS services kan tilknyttes account. Figur 46: beskæftigelse på AWS account oprettelse. AWS EC2 service oprettelse Efter oprettelse af bruger account er det muligt at tilknytte AWS services. I nedenstående Figur 47 oprettes EC2 service vha. web service menu interfacet Sign up for Amazon EC2. Side 86 af 159

87 Figur 47: Oprettelse af AWS EC2 service [182] Figur 48 viser, at den EC2 service tilknyttes den eksisterende bruger account. Brugeren foretager login på AWS account og accepterer tilknytning af service. Figur 48: AWS EC2 oprettelse eksisterende bruger account tilknyttes service[182]. Når EC2 service er tilnkyttet AWS bruger account medtages en bekræftelse, Figur 49. Side 87 af 159

88 Figur 49: AWS EC2 service aktiverings bekræftelse. Andre services der anvendes i denne rapport oprettes på tilsvarende måde. Efter oprettelse af bruger account og EC2 service er det muligt at styre service vha. web services interface [183]. Dette giver mulighed for at administrere EC2 og andre serives i AWS. Figur 50 viser AWS management console for konteksten EC2. Det er her muligt bl.a. at skifte datacenter region for instanser, starte og stoppe instanser og oprette instans snapshots. Figur 50: AWS Management console - EC2 [183]. Side 88 af 159

89 Oprettelse af sikkerheds credentials AWS har adgangskontrol på services i form af credentials, som skal anvendes for at benytte servicen. Figur 51 viser credentials anvendelsesområder [185]. Figur 51: AWS sikkerheds credentials anvendelsesområder [185]. Til anvendelsesområderne benyttes credentials af forskellige typer. Disse er vist i Tabel 23. Version REST eller Query API forespørgsel til AWS service SOAP API forespørgsel til AWS service EC2 kommando line værktøjer Credential type Access kerys X.509 certificates X.509 certificates Beskrivelse AWS credentials fil med secret key og access key. Nøglerne genereres på Amazon site, downloades og indsættes i AWS credentials fil. RSA kodet private key fil og RSA kodet certificate fil genereres på Amazon site og downloades RSA kodet private key fil og RSA kodet certificate fil genereres på Amazon site og downloades RSA kodet private key fil genereres på Amazon site og downloades Oprettelse af forbindelse til EC2 key EC2 instans pairs Tabel 23: Beskrivelse af AWS credentials typer og anvendelse [185]. Access keys anvendes til at tilgå AWS services, som f.eks.auto Scaling baseret på REST API. Benyttes i stedet SOAP API anvendes i stedet X.509 certificates. EC2 service kommando line værktøjer anvender ligeliges X.509 certificates til f.eks. start af instanser. Når en instans er startet kan der oprettes en SSH baseret forbindelse, denne er baseret på EC2 key pairs. I denne rapport skal alle credential typer anvendes i udviklingen af case system, derfor gennemgås i det efterfølgende, hvorledes disse oprettes. Side 89 af 159

90 Credentials kan oprettes og downloades fra AWS bruger account web service interface [184] vist på Figur 52. Figur 52: Adgang til AWS credentials "Security Credentials" [184]. Figur 53 viser credentials Access keys, X.509 certificates og key pairs. Access keys og X.509 certificates kan oprettes på denne side. Figur 53: AWS credentials oversigt [184]. X.509 certificates generes og downloades til følgende filer, hhv. private key og certificate, Figur 54 Side 90 af 159

91 pk-m3bhqkyeqyl35bensoobwf4pj36362sz.pem cert-m3bhqkyeqyl35bensoobwf4pj36362sz.pem Figur 54: X.509 certificates filer. Access keys, hhv. secret key og access key kopiers til AWS credentials fil, Figur 55. Figur 55: Credential fil, som anvendes til CLI værktøjer og services. EC2 key pairs skal oprettes vha. AWS management console, som gennemgås i det efterfølgende. Figur 56, Figur 58 og Figur 59 viser de enkelte steps i oprettelsen af EC2 key pair, som anvendes til etablering af SSH forbindelse til EC2 instanser. Figur 56: Oprettelse af EC2 key pair i AWS management console [183]. Side 91 af 159

92 Figur 57: Navngivning af EC2 ley pair. Figur 58: Bekræftelse på oprettelse af EC2 key pair. Side 92 af 159

93 Figur 59: EC2 key pair oprettet og downloadet. Side 93 af 159

94 Oprettelse af EC2 instans sikkerhedsgruppe Det sidste emner vedrørende sikkerhedsaspektet, som skal konfigureres, er oprettelse af en sikkerhedsgruppe[186] for EC2 instanserne. En sikkerhedsgruppe bestemmer, hvilke forbindelser der tillades til en EC2 instans herunder f.eks. SSH. Sikkerhedsgruppen indeholder regler eller politikker, som beskriver hvilke type af forbindelser, der kan oprettes. Dette svarer til funktionalitet i en firewall. I casen, som udvikles, er der behov for SSH tilgang til den enkelte instans for at kunne indføre et runtime miljø og mekanisme for overførsel af instans software. Derfor oprettes en regel, der tillader forbindelser til instansen af protokol typen SSH. Oprettelsen af sikkerhedsgruppen foregår vha. AWS management console og vises i Figur 60, Figur 61 og Figur 62. Figur 60: Oprettelse af sikkerhedsgruppe for EC2 instans, som tillader SSH forbindelser [183]. Side 94 af 159

95 Figur 61: Navngivning af sikkerhedsgruppe for EC2 instans. Figur 62: Sikkerhedsgruppe oprettet for EC2 instans med forbindelse på port 22, SSH. Side 95 af 159

96 Installation af Java SDK AWS Java SDK downloades fra [187]. Efter udpakning af arkiv fil findes fil strukturen i Figur 63. Figur 63: AWS Java SDK fil struktur[187]. AWS Java SDK indeholder Java dokumentation af AWS APIer i folderen documentation. Folderen lib indeholder AWS specifikke libraries og folderen third-party eksterne projekt libraries, som f.eks. JSON og logging funktionalitet. Folderen samples indeholder test applikationer for services S3, SimpleDB, Simple Queue, Relational Database service(rds) og EC2. Afprøvning af account oprettelse, services aktivering og AWS credentials afprøves ved at afvikle AWSConsoleApp, som stimulerer EC2 service og lagringsservices S3 og SimpleDB. Til sample applikationerne leveres en Ant build konfiguration med et run target til afvikling af applikationen. Resultatet af dette ses i Figur 64. Q:\samples\AwsConsoleApp>ant run Buildfile: Q:\samples\AwsConsoleApp\build.xml run: [1usajava] =========================================== [1usajava] Welcome to the AWS Java SDK! [1usajava] =========================================== [1usajava] :03:13 com.amazonaws.http.httpclient execute [1usajava] INFO: Sending Request: POST / Parameters: (Action: DescribeAvailabilityZones, SignatureMethod: HmacSHA256, AWSAccessKeyId: <vises ikke>, Version: , SignatureVersion: 2, Timestamp: T16:03:13.042Z, Signature: KulbNisZzxUpKHg46D3lLJWFtE+9eTO8MMLr12YX1To=, ) Side 96 af 159

97 [1usajava] :03:14 com.amazonaws.http.httpclient handleresponse [1usajava] INFO: Received successful response: 200, AWS Request ID: 004e5d6c e58-a04eedaf0e55e753 [1usajava] :03:14 com.amazonaws.http.httpclient execute [1usajava] INFO: Sending Request: POST / Parameters: (Action: DescribeInstances, SignatureMethod: HmacSHA256, AWSAccessKeyId: <vises ikke>, Version: , SignatureVersion: 2, Timestamp: T16:03:14.957Z, Signature: 3putak2R5jeKKNrOCkFCljOXg65eJjl6Y9VETzK/zoQ=, ) [1usajava] You have access to 4 Availability Zones. [1usajava] You have 0 Amazon EC2 instance(s) running. [1usajava] :03:15 com.amazonaws.http.httpclient handleresponse [1usajava] INFO: Received successful response: 200, AWS Request ID: 79b3abd6-b6f8-45f3-a453- dfcc5a7ac3c4 [1usajava] :03:15 com.amazonaws.http.httpclient execute [1usajava] INFO: Sending Request: POST / Parameters: (MaxNumberOfDomains: 100, Action: ListDomains, SignatureMethod: HmacSHA256, AWSAccessKeyId: <vises ikke>, Version: , SignatureVersion: 2, Timestamp: T16:03:15.188Z, Signature: XlAqy/uB0WgIq5k6pi87hhWzuzvaEeOLV/wt3SPxRPo=, ) [1usajava] You have 0 Amazon SimpleDB domain(s)containing a total of 0 items. [1usajava] :03:16 com.amazonaws.http.httpclient handleresponse [1usajava] INFO: Received successful response: 200, AWS Request ID: ad278a55-7f42-f991-0e95- d4e f1 [1usajava] :03:16 com.amazonaws.http.httpclient execute [1usajava] INFO: Sending Request: GET / Headers: (Authorization: AWS <vises ikke>:28khzzzjbdx0szyiriywqlelndy=, Date: Fri, 14 Jan :03:16 GMT, Content-Type: application/x-www-form-urlencoded; charset=utf-8, ) [1usajava] You have 0 Amazon S3 bucket(s), containing 0 objects with a total size of 0 bytes. [1usajava] :03:17 com.amazonaws.http.httpclient handleresponse [1usajava] INFO: Received successful response: 200, AWS Request ID: 026A803B5636EA6A BUILD SUCCESSFUL Total time: 5 seconds Figur 64: Afviklingsresultat af Java SDK AWSConsoleApp. Alle services forespørgsler blev gennemført uden fejl for de 3 services. Side 97 af 159

98 Konfiguration af API service kommando værktøjer I udviklen af case anvendes kommando line API tools til konfiguration af det samlede system. Udvikningsværktøjer er samlet i et katelog for AWS [190]. Kommando line værktøjer anvendes for services Cloud Watch[193], Auto Scaling[192], Simple Notification[194] og EC2[191]. Disse tools er Java baseret applikationer, som vha. wrapper scripts kalder command line interpreters (CLI) Java applikationer, som sender service forespørgsler. Kommando line værktøjerne antager miljø variabler er konfigureret for placering af værktøjer i filsystem, adresse på service endpoint og credentials filer. Denne information er samlet fra developer guides for de enkelte services og et script til konfiguration af miljø, som anvendes til udvikling findes i Figur 65. echo off rem Tools execution environment subst f:. f: set AWS_TOOLS_DIR=c:\Temp\master-evu-au-2010\tools set AWS_CREDENTIALS=f:\credentials set ANT_HOME=%AWS_TOOLS_DIR%\apache-ant set AWS_AUTO_SCALING_HOME=%AWS_TOOLS_DIR%\AutoScaling set AWS_EC2_HOME=%AWS_TOOLS_DIR%\ec2-api-tools set AWS_CLOUDWATCH_HOME=%AWS_TOOLS_DIR%\CloudWatch set AWS_SNS_HOME=%AWS_TOOLS_DIR%\SimpleNotificationServiceCli set JAVA_HOME=c:\Program Files\Java\jdk1.6.0_23 set PATH=%PATH%;%AWS_AUTO_SCALING_HOME%\bin;%AWS_EC2_HOME%\bin; %AWS_CLOUDWATCH_HOME%\bin;%AWS_SNS_HOME%\bin set PATH=%PATH%;%JAVA_HOME%\bin;%ANT_HOME%\bin;c:\cygwin\bin rem END----Tools execution environment rem Specific for applications rem AutoScaling set AWS_AUTO_SCALING_URL= set AWS_CREDENTIAL_FILE=%AWS_CREDENTIALS%\accesskeys\credential-file.txt rem EC2 set EC2_HOME=%AWS_EC2_HOME% set EC2_CERT=%AWS_CREDENTIALS%\x509cert\cert-M3BHQKYEQYL35BENSOOBWF4PJ36362SZ.pem set EC2_PRIVATE_KEY=%AWS_CREDENTIALS%\x509cert\pk- M3BHQKYEQYL35BENSOOBWF4PJ36362SZ.pem set EC2_URL= rem SNS set AWS_SNS_URL= rem Cloudwatch set AWS_CLOUDWATCH_URL= rem END-----Specific for applications Figur 65: Windows miljø opsætning for AWS kommando line værktøjer. Verifikation af opsætning for de enkelte kommandoværktøjer findes i Figur 66, Figur 67, Figur 68 og Figur 69. Det bemærkes, at en kommando oversigt ikke kunne fremvises for EC2 værktøj, pga. en værktøjs fejl. Side 98 af 159

99 Figur 66: Verifikation af CLI værktøjer Auto Scaling, CloudWatch, Simple Notification og EC2 versioner. Figur 67: Auto Scaling værktøj kommandooversigt. Side 99 af 159

100 Figur 68: CloudWatch værktøj kommandooversigt. Figur 69: Simple Notification værktøj kommandooversigt. Side 100 af 159

101 Installation af Java AWS tool Eclipse Elcipse AWS toolkit downloades fra [193] og installeres ved at følge getting started dokumentet Getting Started with Amazon EC2 Management in Eclipse [194]. Efter installation findes et nyt perspective i Eclipse kaldet Amazon EC2 Management og tilhørende views: EC2 AMIs, EC2 Elastic Block Storage, EC2 Instances og EC2 Security Groups. Udover dette findes en oversiget for AWS ressourcer i en portal side. Ændringer til Eclipse ses i Figur 70, Figur 71, Figur 72, Figur 73 og Figur 74. Figur 70: Aktivering af AWS Eclipse perspective Amazon EC2 Management Figur 71: Aktivering af AWS Eclipse Views. Side 101 af 159

102 Figur 72: Views i perspective. Figur 73: AWS Toolkit Overview. Side 102 af 159

103 Oprettelse af projekt Oprettelse af case projekt udføres vha. projekt wizard installeret, som del af AWS Eclipse toolkit. Efter oprettelse af projekt et AWS libraty afhængigheder og credentials fil oprettet i roden af folder strukturen. De enkelte steps er vist i Figur 74, Figur 75 og Figur 76. Figur 74: Menu tilgang. Figur 75: Projekt oprettelse. Side 103 af 159

104 Figur 76: Projekt struktur. Problemer Ved den første test for opstart af EC2 m1-large instanser blev der den 15/ fundet kapacitets problemer for regioner USA (us-east-1a og us-west- 1c) og APAC (ap-southeast-1a og ap-southeast-1b), se Figur 77. Historikken for den 10. og 12. december (Figur 78 og Figur 79) viser tilsvarende problemer, men der var ikke rapporteret problemer for den 15. december. Fejlen blev rapporteret og den 16. december kunne EC2 m1.large instanser i availability zones: us-west-1c, ap-southeast-1a og ap-southeast-1b startes. Det skal bemærkes, at hændelsen ikke kan ses i status historikken. Figur 77: EC2 kapacitets problem 15. december 2010, region USA. Side 104 af 159

105 Figur 78: EC2 service status for region USA, 10. december Figur 79: EC2 service status for region EU, 12. december Tidsforbrug Der blev anvendt ca. 5 arbejdsdage til dette scenarie. Dette skyldes afklaring af konfiguration af kommando line værktøjer herunder ændringer af endpoint til EU regionen og opsætning af credentials. Hermed skulle der bruges mere tid på studie af developer guides for de enkelte services for at finde løsninger. Derudover blev der fundet et kapacitets problem for EC2 regioner USA og APAC, som skulle undersøges og rapporteres til Amazon. Konklusion Den estimerede tid for scenariet blev ikke opfyldt pga. tidligere nævnte problemer. Amazon cloud services kræver flere konfigurations aktiviteter før en cloud service kan anvendes til udvikling. Dette skyldes bl.a. antallet af services der skal anvendes i rapport case og sikkerhedskonceptet for platformen. Efter denne konfiguration kan platformen anvendes uden yderligere væsentlig konfiguration fra brugerens side. Side 105 af 159

106 7.3.2 Usability scenarie 2: Udvikling af første services Der arbejdes med at få et afgrænset artefakt at virke. Eksempelvis kan der arbejdes videre med det realiserede interface fra det foregående scenarie. Første interaktion afslutter opgaven. En log besked fra teknologien, der viser en service er registreret eller andet der viser en besked er sendt og modtaget fra teknologien til den nye klasse eller omvendt. Kilde Stimulus Artefakt(er) Miljø Respons Måling Forfatteren af rapport og udvikleren af case Lære at lave services, der kommunikerer med hinanden. Kodegenerering, command line interface, associeringsfunktionalitet Linux / Windows platform, med udviklingsmiljø konfigureret. Understøttelse for udvikling af interservice kommunikation. Opgaven skal udføres på under 7 timer Proces steps 1. Valg af arkitektur style 2. Beskrivelse af komponenter 3. Implementering 4. Test AWS cloud platformen stiller kvalitetskrav til arkitekturen, som skal realisere CP09 casen. De enkelte virtuelle EC2 instanser har ikke kendskab til andre instansers netværks adresser, således en forbindelse kan oprettes mellem komponenterne i systemet. Dette er desuden ikke en hensigtsmæssig egenskab, da instanserne kan blive nedlukket eller genstartet, som følge af udførsel af adfærdspolitikker for, hvordan instansen skal opføre sig, hvis f.eks. CPU overstiger en fastsat grænseværdi. Derfor stilles følgende krav til arkitekturen: - Komponenter skal være uafhængige af hinanden og må derfor ikke kommunikere direkte med hinanden. - Modifiability: det skal være muligt at indsætte flere sensorer eller andre komponenter uden at foretage konfiguration Til at finde en løsningsarkitektur til disse krav anvendes arkitektur style. Definition [196]: en arkitektur style er en beskrivelse af komponent typer og et pattern for deres runtime kontrol og data overførsel. En arkitektur style definerer desuden begrænsninger for komponent typer og interaktions pattern. Arkitektur styles beskriver også arkitekturer med specifikke kvaliteter, således at kvalitetskrav til en arkitektur opfyldes, hvis en given arkitektur style anvendes. En arkitektur style eller pattern beskrives ligesom med design patterns med et navn, en kontekst, et gentaget problem som optræder i konteksten og en løsning. Til løsningsarkitekturen er fundet to kandidat arkitektur styles[195]: Blackboard og Broker. Blackboard er en style til ved hjælp af flere Side 106 af 159

107 specialiserede komponenter at samle deres viden for løse et problem. Broker er en style til et distribueret og heterogent system, hvor flere uafhængige komponenter skal kommunikere med hinanden. Begge har som kvalitet muligheden for ændringer af komponenter i systemet, hvis flere sensorer f.eks. skal indføres. I begge syles er klienter også uafhængige af hinanden. Broker style kræver en broker komponent, hvor services eller komponenter kan registreres og udbyde interfaces til andre klienter. Denne komponent findes ikke i AWS platformen. Denne skal derfor udvikles eller installeres separat. Blackboard syle består af 3 komponenter, se Figur 80. Blackboard har til ansvar at styre data, som bliver sendt til Blackboard. Knowledge source har til ansvar at evaluere egen relevans for at løse et problem eller hypotese på Blackboard. Knowledge source opdaterer Blackboard med løsninger. Control er ansvarlig for at monitorer Blackboard og planlægge, hvornår knowledge sources skal aktiveres. Denne style kan anvendes i AWS platformen, da der findes en queue service (Simple Queue Service), som kan anvendes til Blackboard komponenten. Sensorer, aktuatorer kan kommunikere vha. denne service. Control komponenten bliver en del af knowledge source, således f.eks. CP09 control selv bestemmer hvornår Blackboard aflæses. Figur 80: Blackboard komponenter og design pattern[195]. Der skal vælges en datastruktur til for data der opdateres i queue service. Dermed kan CP09 control, actuator og monitor sende og modtage beskeder og vide, hvordan de skal aflæses. Beskedsstrukturen ses i Figur 81. Type elementet angiver komponent navnet på afsenderen af beskeden. Message elementet angiver en besked fra afsenderen f.eks. at den er opstartet. Value elementer angiver værdier fra sensorer. MachineName elementet er netværksnavnet for den virtuelle maskine. MachineAddress elementet er Side 107 af 159

108 netværksadressen eller IP adressen for den virtuelle maskine. Timestamp elementet angiver tidspunktet beskeden var afsendt. Message { "Type" : "", "Message" : "", "Value" : "", "MachineName" : "", "MachineAddress" : "", "Value" : "", "Timestamp" : "" } Figur 81: CP09 JSON besked data struktur. I forhold til den valgte arkitektur style beskrives CP09 komponenternes ansvarsområder i Tabel 24. Komponent Ansvar Monitor Der oprettes en Monitor kø, hvortil Control knude kan sende sensorværdier læst fra sensor kø og SNS service kan sende alarmer fra CloudWatch. Hertil sendes også hændelser foretaget af Actuator f.eks. ved åbning af ventil. Desuden sendes deployment beskeder, når komponenter starter i instanser. Monitor knude skal slette beskeder læst fra denne kø. Control Der oprettes en Control kø, hvortil Sensor par knude skriver sensorværdier for temperatur og tryk. Control knude skal slette beskeder læst fra denne kø. Sender deployment besked til Monitor, når komponenter startet instansen Actuator Der oprettes en Actuator kø, hvortil Control sender kommandoer for styring af temperatur, tryk og produktion. Actuator knude skal slette beskeder læst fra denne kø. Sender deployment besked til Monitor, når komponenter startet instansen Sensor Sensor par sender beskeder til Control indeholdende aflæste beskeder. Sender deployment besked til Monitor, når komponenter startet instansen Tabel 24: Beskrivelse af ansvarsområder for komponenter i case [8]. AWS Simple Queue er et distribueret kø system, som anvender redundant lager af beskeder på flere servere, som en availability kvalitetsattribut taktik, vist på Figur 82. En besked sendt til en kø bliver kopieret til flere servere. Figur 82: AWS Simple Queue distrueret kø system[198]. Side 108 af 159

109 Endnu en taktik implementeret i kø systemet er en timer funktion på beskedsbehandlingen. Når modtageren læser en besked fra køen har den 30 sekunder til behandlingen af beskeden. Hvis modtageren ikke sletter beskeden inden 30 sekunder efter den er modtaget, returnere den til køen. Dette skal sikre mod, at en besked ikke går tabt, som følge af f.eks., at modtagerens virtuelle maskine fejler. Med anvendelsen af style ser CP09 ud som component og connector view vist i Figur 83. Figur 83: CP09 component og connector view. CP09 systemets realisering er blevet struktureret som pakkestrukturen for module view i Figur 84. Side 109 af 159

110 Figur 84: CP09 Module view - pakker. Pakke cp09.monitorgui cp09.monitor cp09.sensor cp09.actuator cp09.control cp09.logging cp09.instance cp09.queue cp09.message Beskrivelse Denne pakke indeholder realiseringen af GUI delen for Monitor og Controller og View delen af MVC pattern Denne pakke indeholder realiseringen af Monitor model delen af MVC pattern. Denne pakker indeholder realiseringen af temperatur og tryk sensorer med simulerede sensor værdier. Denne pakke indeholder realiseringen af Actuator. Denne pakke indeholder realiseringen af Control. Denne pakke indeholder realiseringen af logging funktionalitet til konsol og fil log. Denne pakke indeholder realiseringen af funktionalitet til kommunikation med EC2 service og Auto Scaling service. Denne pakke indeholder realiseringen af funktionalitet til kommunikation med Simple Queue service. Denne pakke indeholder realiseringen af CP09 JSON baseret beskeds system. Figur 85: CP09 pakke beskrivelse. Beskrivelse af pakke indhold findes i Module views på Figur 86, Figur 87, Figur 88, Figur 89, Figur 90. Side 110 af 159

111 Figur 86: MonittorGUI realisering. Figur 87: Monitor realisering. Side 111 af 159

112 Figur 88 Control realisering. Figur 89: Sensor realisering. Figur 90: Actuator realisering. Side 112 af 159

113 Fælles for komponent realiseringerne er, hvordan beskeder læses på queue Blackboard og efterfølgende behandles. En timer trigger hvert sekund eller hvert 10. sekund afhængig af om det er Sensor, Monitor eller Actuator komponent. Opsætning af køer og timer er vist på Figur 91 for Monitor. Beskedsbehandlingen er vist for Monitor på Figur 92. public MonitorImpl (QueueFactory queuefactory, InstanceFactory instancefactory) { // Logging logconfig = new ConfigureLogging(getClass().getName()); log = logconfig.getlogger(); // Create EC2 and Auto scaling instances try { this.ec2inst = instancefactory.createec2instance(); this.ec2scale = instancefactory.createec2scaling(); } catch (InstanceException e) { log.warning("unable to create EC2 instances error received " + e.getmessage()); System.exit(1); } try{ // Create queues this.queuemon = queuefactory.createqueue(); this.queuemon.createqueue("cp09mon"); this.queuemon.setaccess("arn:aws:sns:eu-west-1: :cw-alarms-cp09- topic"); this.queuectrl = queuefactory.createqueue(); this.queuectrl.createqueue("cp09ctrl"); this.queueactuator = queuefactory.createqueue(); this.queueactuator.createqueue("cp09actuator"); } catch (QueueException ce) { log.warning("unable to create queue error received " + ce.getmessage()); System.exit(1); } // Commence generating temperature readings each minute // Swing timer is executed in same thread as the GUI therefore the timer is // blocked waiting for the actionperformed method to finish executing new Timer(1000, this).start(); } Figur 91: Monitor - opsætning af køer og timer. public void actionperformed(actionevent e) { try { // Retrieve queues status information this.monitorlistener.updatequeueact(this.queueactuator.getqueuemessagesize()); this.monitorlistener.updatequeuemon(this.queuemon.getqueuemessagesize()); this.monitorlistener.updatequeuectrl(this.queuectrl.getqueuemessagesize()); // Receive queue messages List<Message> messages = this.queuemon.receivemessages( ); for (Message message : messages) { Side 113 af 159

114 } String rh = message.getreceipthandle(); String msg = message.getbody(); log.info("message type received " + msg); // We have a default visibility time of 30 sec before the message is // released again to the message queue CP09Message cp09message = new CP09MessageImpl(); cp09message.decodeparameters(msg); String msgtype = cp09message.getsender(); String msgcontent = cp09message.getmessage(); log.info("message type received " + msgtype); log.info("message content received " + msgcontent); this.queuemon.deletemessage(rh); // Process received event MonitorEvent monitorevent = null; if (msgtype.compareto("cp09sen")==0){ monitorevent = new MonitorEventSensor(); } else if (msgtype.compareto("cp09ctrl")==0){ monitorevent = new MonitorEventCtrl(); } else if (msgtype.compareto("cp09act")==0){ monitorevent = new MonitorEventActuator(); } else if (msgtype.compareto("notification")==0){ monitorevent = new MonitorEventNotification(); } else { log.warning("invalid messge received: " + msg); return; } monitorevent.processevent(msg, this.monitorlistener); } catch (QueueException ce) { log.warning("message handling failed error received " + ce.getmessage()); } catch (CP09MessageException me) { log.warning("message handling failed error received " + me.getmessage()); } } Figur 92: Monitor - beskedsbehandling. Der benyttes Factory design pattern for oprettelse af queue og EC2 instans objekter. Dette er valgt for at indkapsle konfigurationen af objekterne til et sted og fratage dette ansvar fra komponenterne. Desuden giver det testability kvalitetsattributten for arkitekturen, således, at andre factories kan anvendes i test konteksten. Eksempel på dette er vist på Figur 93. public static void main(string[] args) { if(args.length < 1) { System.err.println("Credentials file needed"); System.exit(1); } Side 114 af 159

115 // GUI creation MonitorGUIImpl monitorguiimpl = new MonitorGUIImpl("CP09Monitor", "Sensor values"); // Monitor component Monitor ts = new MonitorImpl(new QueueFactoryImpl(args[0], "sqs.eu-west- 1.amazonaws.com"), new InstanceFactoryImpl(args[0], "ec2.eu-west-1.amazonaws.com", "autoscaling.eu-west-1.amazonaws.com")); // Add GUI as listener to Monitor events ts.addmonitorlistener(monitorguiimpl); } Figur 93: Anvendelse af Factory pattern - Monitor. Deployment view for CP09 systemet i Amazon cloud platformen er vist på Figur 94. Side 115 af 159

116 Figur 94: CP09 deployment view - cloud service. Der er ikke viset software dependencies af layout hensyn. Workstation er ikke en virtuel cloud instans, men findes ved brugeren og link til EC2 indikerer status information fra instanser. Protokol anvendt mellem EC2 service og EC2 instanser, Simple notification og Cloud Watch, Cloud Watch og Auto Scaling og EC2 service og Auto Scaling er ikke kendt. Deployment test AWS tool SDK indeholder ikke et build system eller beskriver en bestemt fil struktur, derfor vælges Ant build script til styring af build konfiguration. Der beskrives targets for komponenter, der skal eksekverer i knuder: Actuator, Control og Sensor. Disse er vist på Figur 95. Deployment af CP09 systemet på lokal maskine er vist på Figur 96 Side 116 af 159

117 Figur 95: CP09 Ant build targets. Side 117 af 159

118 Figur 96: CP09 system test ved lokal deployment. Konklusion Scenariet blev ikke udført indenfor 7 timer som estimeret med. Dette skyldes detalje studie af Simple Queue service. Der blev fundet en fejl i adgangssystemet for Simple Queue service, hvor det er muligt at give adgang for andre services eller bruger accounts. CP09 systemet skal have adgang for Simple Notification service, således at Monitor kan gøre brugeren opmærksom på Auto Scaling aktiviteter. Adgangsprofilen beskrives vha. en policy, som er baseret på JSON. Denne policy indeholder et condition element, som beskriver under hvilke betingelser, der gives adgang til køen. Dette condition element skal være baseret på et StringEquals element ellers evalueres policy forkert[199]. Side 118 af 159

119 7.3.3 Usability scenarie 3: Tilvejebringelse af instanser I dette scenarie skal CP09 virtuel maskine instanser oprettes og konfigureres med Java runtime miljø for udrulning af komponenter Control, Actuator og Sensor. Kilde Stimulus Artefakt(er) Miljø Respons Måling Forfatteren af rapport og udvikleren af case Lære at oprette og konfigurere instanser Fejlhåndteringsfunktionalitet Linux / Windows platform, med udviklingsmiljø konfigureret. Understøtte oprettelse og konfiguration af instanser Opgaven skal kunne udføres på under 7 timer. Proces steps 1. Oprettelse af CP09 virtuel maskine instans image reference 2. Oprettelse af CP09 specifikke virtuel maskine instans images 3. Test Side 119 af 159

120 Oprettelse af CP09 virtuel maskine instans image reference Der anvendes et reference virtuel maskine image, som alle andre virtuelle maskiner i CP09 baseret på. Dette sikre, at alle virtuelle maskine er baseret på det samme operativ system og runtime miljø. De individuelle virtuelle maskiner, hvor CP09 komponenter afvikles, oprettes ved at ændre på et opstarts script. De enkelte steps i oprettelse af reference CP09 virtuel maskine instans reference består i: - Valg af Amazon Machine Image (AMI) - Opstart af valgte AMI og oprettelse af forbindelse til virtuel maskine for ændring af runtime miljø - Kopier (snapshot) tilstanden af virtuel maskine til lager (Elastic Block Store) I alle aktiviteterne i dette scenarie anvendes EC2 kommando line værktøj til at tilgå EC2 service [200]. Amazon tilbyder AMIs baseret på forskellige operativ systemer og konfigurerede runtime miljøer herunder applikationer. Der vælges et AMI til CP09 systemet uden installeret runtime miljø og applikationer for at sikre kontrol over runtime miljøet og minimere risiko for konflikter i et eksisterende miljø og den installerede komponent kode. Da forfatteren har kendskab og erfaring med Ubuntu operativ system vælges dette for AMI. EC2 understøtter snapshot af instanser baseret på instans type m1.small og større. Derfor vælges denne. EC2 understøtter mulighed for at finde specifikke AMI, som skal opfylde et specifikt formål. Denne er anvendt i Figur 97 for at finde et AMI. ec2-describe-images -a -F "name=*ubuntu*10.10*" -F "root-device-type=ebs" -F "architecture=i386" -headers --region euwest-1 Resultat ImageID Name Owner Architecture RootDeviceType ami- 18b59f6c /ebs/ubuntu-images- milestone/ubuntu-maverick rc-i386- server ami- 465c /ebs/ubuntu-images- milestone/ubuntu-maverick beta-i386- server amif46f5a i386 ebs i386 ebs /ebs/ubuntu-images/ubuntumaverick i386-server i386 ebs Figur 97: Valg af AMI Det sidste AMI på listen vælges for en stabil release af Ubuntu En virtuel instans startes for dette AMI baseret på instans type m1.small i Figur 98. Side 120 af 159

121 ec2-run-instances ami-465c6932 -k cp09 -t m1.small --region eu-west-1 ec2-describe-instances ami-465c region eu-west-1 Resultat Type ReservationID Owner Groups Platform RESERVATION r-f CP09 INSTANCE i-64101e13 ami-465c6932 ec eu-west-1.compute.amazonaws.com ip eu-west-1.compute.internal running cp09 0 m1.small T18:25: eu-west-1b aki- 4deec439 monitoring-disabled ebs paravirtual xen BLOCKDEVICE /dev/sda1 vole8b T18:26:04.000Z Figur 98: Opstart af AMI for instans type m1.small. Der oprettes en SSH forbindelse til startede virtuelle maskine med sikkerhedscredentials oprettet i tidligere scenarie. Dette vises i Figur 99. Figur 99: Oprettelse af SSH forbindelse til virtuel maskine. På Figur 100, Figur 101 og Figur 102 verificeres virtuel maskine specifikation for m1. small instans typen. Hukommelse er 1.7GB, CPU er Xeon E GHz og lager er 160GB med 15GB root partition baseret på EBS. Dette passer med specifikation for instans typen m1.small. De 160GB instans lager er ikke persistent mellem ændringer i lifecycle for instansen, det vil sige, at filer gemt, mens den virtuelle maskine er startet kan ikke findes igen, hvis den stoppes og startes igen. Desuden understøttes EC2 snapshot funktionalitet kun kopiering af EBS partition. Side 121 af 159

122 Figur 100: Hukommelse specifikation for virtuel maskine. Figur 101: CPU specifikation for virtuel maskine. Side 122 af 159

123 Figur 102: Lager specifikation af virtuel maskine. I Figur 103 og Figur 104 vises installation af Ant og Java runtime miljø samt versionsstyrings værktøjet Subversion. Ant anvendes til afvikling af kode for CP09 komponent herunder kompilering af source kode. Java er runtime miljø for CP09 komponent og Subversion anvendes som respository, hvor source kode til CP09 downloades fra. Figur 103: Installation af Ant og Java runtime miljø i instans. Side 123 af 159

124 Figur 104: Installation af Subverison i instans. Den virtuelle maskine anvender et startup script, som i den virtulle maskine bliver kaldt af Linux boot init systemet. Derudover skal den virtuelle anvende en credentials fil for tilgang af AWS. Disse filer uploades til den virtuelle maskine i Figur 105 og Figur 106. scp -i cp09.pem../accesskeys/awscredentials.properties ubuntu@ec eu-west- 1.compute.amazonaws.com:/home/ubuntu Figur 105: Upload af AWS credentials til instans. scp -i cp09.pem \cp09 ubuntu@ec eu-west-1.compute.amazonaws.com:/home/ubuntu Figur 106: Upload af instans init opstarts script. Opstarts script ses i Figur 107. Når den virtuelle maskine starter downloades komponent source kode fra Subversion repository og Ant build target kaldes for den specifikke komponent. #!/bin/sh # # /etc/init.d/cp09 -- startup script for the deployment of CP09 components # # Environment configuration JAVA_HOME=/usr/bin/java AWSACCESSKEY= case "$1" in start) echo "Starting CP09 Deployment... " # 1 Update source # /usr/bin/svn co /home/ubuntu/cp09 # 2 Deploy component on target machine # ant -f /home/ubuntu/cp09/build.xml DeployCtrk -Dcred=/home/ubuntu/AwsCredentials.properties ;; stop) echo "not yet implemented" ;; restart force-reload) $0 stop $0 start ;; status) echo "not yet implemented" Side 124 af 159

125 ;; *) echo "Usage: $0 {start stop restart status}" exit 1 ;; Esac Figur 107: Init proces script De individuelle operationer i scriptet testes i Figur 108 og Figur 109. Scriptet registreres i instansens Ubuntu init system på Figur 110 og scriptet testes ved at verificere indholdet af instans boot log efter genstart i Figur 111. Figur 108: Test af Subversion source kode checkout. Figur 109: Test at Ant build target for Control. Side 125 af 159

126 Figur 110: Registrering af init proces script på forskellige runlevels. Figur 111: Instans system boot log for afvikling af Init script. Hermed er det virtuelle maskine instans reference image konfigureret og der kan foretages et snapshot af den virtuelle maskine, som anvendes til CP09 systemets andre komponenter. Den virtuelle maskine stoppes og et shapshot foretages. Dette er vist i Figur 112 og Figur 113 samt Figur 114 og Figur 115. Side 126 af 159

127 ec2-stop-instances i-64101e13 --region eu-west-1 Resultat INSTANCE i-64101e13 running stopping Figur 112: Den virtuelle maskine instans stoppes. ec2-describe-instances --region eu-west-1 Resultat RESERVATION r-f CP09 INSTANCE i-64101e13 ami-465c6932 stopped cp09 0 m1.small T18:25: eu-west-1b aki-4deec439 monitoring-disabled ebs paravirtual xen BLOCKDEVICE /dev/sda1 vol-e8b T20:59:06.000Z Figur 113: Verifikation af, at virtuel maskine er stoppet. ec2-create-image -n "Reference AMI based on Ubuntu used for all CP09 components" i e13 --region eu-west-1 Resultat IMAGE ami-3384b147 Figur 114: Udførsel af snapshot for CP09 virtuelle maskine reference instans. ec2-describe-images -o self --region eu-west-1 Resultat IMAGE ami-bda693c /ref-ami-cp available private i386 machine aki ebs paravirtual xen BLOCKDEVICEMAPPING /dev/sda1 snap-d0921db9 10 IMAGE ami-3384b /Reference AMI based on Ubuntu used for all CP09 components pending private i386 machine aki-4deec439 ebs paravirtual xen BLOCKDEVICEMAPPING /dev/sda1 snap-723eb61b 15 Figur 115: Snapshot af CP09 AMI reference. Oprettelse af CP09 specifikke virtuel maskine instanser Reference CP09 AMI anvendes til at oprette AMIs for komponenterne Sensor, Control og Actuator. Dette udføres ved at følge de samme operationer som ved oprettelse af reference AMI. - Reference AMI startes - SSH forbindelse etableres til virtuelle maskine - Ændringer til startup script udføres - Snapshot udføres Ændringerne der skal udføres til startup script ses i Figur 116. Ant build target indsætte for den specifikke CP09 komponent. Side 127 af 159

128 #!/bin/sh # # /etc/init.d/cp09 -- startup script for the deployment of CP09 components # # Environment configuration JAVA_HOME=/usr/bin/java AWSACCESSKEY= case "$1" in start) echo "Starting CP09 Deployment... " # 1 Update source /usr/bin/svn co /home/ubuntu/cp09 # 2 Deploy component on target machine # ant -f /home/ubuntu/cp09/build.xml DeployCtrl - Dcred=/home/ubuntu/AwsCredentials.properties Figur 116: Startup script ændres ved at indsætte de enkelte CP09 komponent build targets. Test Når scenariet er fuldføres haves AMIs for CP09 komponenter vist i oversigt på Figur 117. Figur 117: Oversigt over oprettede CP09 AMIs i Amazon Management Console. Konklusion Scenariet blev udført indenfor den estimerede tidsramme på 7 timer. Scenariet handlede om at blive fortrolig med EC2 API for administration af AMI og finde en mekaniske til at levere source kode til de virtuelle maskiner og aktivere komponent ved opstart. Side 128 af 159

129 7.3.4 Usability scenarie 4: Overvågning og SLA Der arbejdes med at lære at realisere SLA og politikker i CP09 systemet vha. AWS. Scenariet afsluttes med en test at det konfigurerede system. Kilde Stimulus Artefakt(er) Miljø Respons Måling Forfatteren af rapport og udvikleren af case Lære at bruge politikker og service level agreements (SLAs) Politikker og SLAs Linux / Windows platform, med udviklingsmiljø konfigureret. Understøtte definition af SLA og politikker herunder monitorering af services Opgaven skal kunne udføres på under 7 timer. Proces steps: 1. Relation af politikker og SLAs til AWS komponenter 2. Oprettelse af Auto Scaling group samt politikker 3. Definition af metrikker og alarmer i CloudWatch 4. Tilknytning af notifikationer for Cloud Watch for alarmer 5. Test Side 129 af 159

130 Relation af politikker og SLAs til AWS komponenter Flere services i AWS platformen skal samarbejde, hvis systemet automatisk skal udføre beslutnunger, som beskrevet i politikker eller SLA. Serives, som skal samarbejde for at realisere politkker i systemer er: EC2, AutoScaling og CloudWatch. EC2 EC2 er ansvarlig for virtuelle maskine instanser [203] lifecycle. Denne service kan starte, stoppe og terminere virtuelle maskine baseret på en given konfiugration eller instans type. Den indsamler desuden information om lifecycle og metrikker for den enkelte instans og videresendere denne information til CloudWatch service. Auto Scaling Auto Scaling introducerer 2 koncepter for automatisk at scalere og håndtere EC2 instanser. En Auto Scale Group og en Launch Configuration. En Auto Scale Group kategoriserer EC2 instanser med lignende karakteristika i en gruppe. En gruppe defineres med et maksimum og minimum af EC2 instanser. En gruppe kan starte EC2 instanser op til maksimum defirneret for at håndtere f.eks. en belastningssiutuation for en applikation. Når situation er afklaret skalere gruppen ned til minimum defineret for gruppen. Instanser startes i availability zones, som angivet i gruppe definitionen. Hvis en availability zone er i problemer startes instansen i en anden availability zone. En gruppe kan tilknyttes politikker for, hvornår en skalerings aktivitet skal foregå og hvilken handling, der skal udføres. En politik beskrives vha. en metrik f.eks. CPU belasting, en grænseværdi for denne metrik og en handling der skal udføres, hvis grænse værdier nås f.eks. skalere op ved at starte en ny EC2 instans. Gruppen starter EC2 instanser baseret på en Launch Configuration, som beskriver instans typen, dvs. specifikationen af den virtuelle maskine og et AMI samt information om sikkerhedsgruppe og credentials. Figur 118 viser en kontekst for en web service, som skalerer op med 10 %, når CPU belastningen kommer over 80 % og skalerer ned igen med 10 %, når CPU belastning reduceres til mindre en 40%.. Figur 118: AutoScaling service - Auto scaling grupper og Launch konfigurationer [201]. Side 130 af 159

131 AutoScaling vil også starte en ny EC2 instans, hvis der modtages information fra EC2 om, at en given EC2 instans er i en ikke tilladelig tilstand. AutoScaling modtager information fra CloudWatch, når en metrik har nået en grænseværdi. Dette betegnes, som en CloudWatch alarm. CloudWatch CloudWatch er et respository af information om indsamlede metrikker fra EC2 instanser. CloudWatch modtager denne information fra EC2 service. Hermed er det muligt at følge udviklingen for en given metrik for en EC2 instans i et historisk perspektiv og danne statistik. CloudWatch tilbyder indsamlede metrikker til andre services. Det er muligt at sætte en alarm for en metrik, således at når en grænseværdi opnås, så sendes en alarm notifikation til abonnenten af alarmen. Metrikker overvåges over en tidsperiode defineret af abonnenten før en den aktiveres. Abonnenter af alarmer kunne f.eks. være AutoScaling eller SNS services. Dette er vist på Figur 119. Figur 119: CloudWatch arkitektur [202]. CloudWatch indsamler forskellige kategorier af metrikker. Disse er vist på Figur 120. Side 131 af 159

132 Figur 120: Tilgængelige CloudWatch metrikker [202]. Oprettelse af Auto Scaling group samt politikker I det følgende gennemgås oprettelsen af Launch configuration, auto scaling gruppe samt skalerings politikker for komponenten Actuator. De samme operationer udføres for Sensor og Control, men vises ikke i gennemgangen. Dette skal være som beskrevet som i CP09 system casen. Der defineres skalerings politikker, som ved en CPU belastning større end 80 % starter en ny EC2 i auto scaling gruppen for den givne komponent. Ligeledes defineres skalerings politikker, som ved en CPU belastning lavere end 40 % skalerer EC2 instanser i gruppen ned med en. Launch configuration for Actuator auto scaling er vist i Figur 121. AMI image er det tidligere oprettede Actuator AMI fra reference AMI. Der vælges en m1.small instans type og sikkerhedsgruppe er den tidligere oprettede CP09 samt det tidligere oprettede key pair cp09. Side 132 af 159

133 as-create-launch-config ActuatorLC --group CP09 --key cp09 --image-id ami-2386b357 --instancetype m1.small Resultat OK-Created launch config Figur 121: Actuator launch configuration. Auto scaling gruppen henviser til den oprettede launch configuration og definerer maksimalt 4 instanser i gruppen samt minimum 2. Auto scaling skal forsøge at allokere instanser i EU regionen, availability zones eu-west- 1a og eu-west-1b. Dette vises på Figur 122. as-create-auto-scaling-group ActuatorGroup --launch-configuration ActuatorLC --availability-zones eu-west-1a eu-west-1b --min-size 2 max -size 4 Resultat OK-Created AutoScalingGroup Figur 122: Actuator auto scaling group. Der defineres 2 auto scaling politikker for Actuator gruppen, den ene skal håndtere, hvilken skalerings aktivitet, der foretages ved en høj CPU belastning og den anden ved en lav CPU belastning. Instanser bliver forøget med 1 ved høf CPU belastning og reduceret med 1 ved lav CPU belastning. Dermed bliver auto scaling reduceret i instanser, når belastningen falder igen. Politikkerne ses i Figur 123 og Figur 124 og resultatet af konfigurationen verificeres i Figur 125 og Figur 126. as-put-scaling-policy ActuatorPolicyUp --auto-scaling-group ActuatorGroup --adjustment=1 --type ChangeInCapacity --cooldown 60 Resultat arn:aws:autoscaling:eu-west-1: :scalingpolicy:94a1cbc4-d173-4f75-aa97- e5abed013d95:autoscalinggroupname/actuatorgroup:policyname/actuatorpolicyup Figur 123: Actuator scaling up politik. as-put-scaling-policy ActuatorPolicyDown --auto-scaling-group ActuatorGroup --adjustment=-1 -- type ChangeInCapacity --cooldown 60 Resultat arn:aws:autoscaling:eu-west-1: :scalingpolicy:73510da7-21c4-483c-91c5-4e :autoscalinggroupname/actuatorgroup:policyname/actuatorpolicydown Figur 124: Actuator scaling down politik. as-describe-policies --headers Resultat SCALING-POLICY GROUP-NAME POLICY-NAME SCALING-ADJUSTMENT ADJUSTMENT- TYPE COOLDOWN POLICY-ARN SCALING-POLICY ActuatorGroup ActuatorPolicyDown -1 ChangeInCapacity 300 arn:aws:autoscaling:eu-west-1: :scalingpolicy:73510da7-21c4-483c-91c5-4e :autoscalinggroupname/actuatorgroup:policyname/actuatorpolicydown ALARM ALARM-NAME POLICY-NAME ALARM ActuatorLowCPUAlarm ActuatorPolicyDown SCALING-POLICY ActuatorGroup ActuatorPolicyUp 1 ChangeInCapacity 300 arn:aws:autoscaling:eu-west-1: :scalingpolicy:94a1cbc4-d173-4f75-aa97- e5abed013d95:autoscalinggroupname/actuatorgroup:policyname/actuatorpolicyup ALARM ALARM-NAME POLICY-NAME ALARM ActuatorHighCPUAlarm ActuatorPolicyUp Figur 125: Politikker defineret for Actuator scaling group. Side 133 af 159

134 as-describe-auto-scaling-groups headers Resultat AUTO-SCALING-GROUP GROUP-NAME LAUNCH-CONFIG AVAILABILITY-ZONES MIN-SIZE MAX-SIZE DESIRED-CAPACITY AUTO-SCALING-GROUP ActuatorGroup ActuatorLC eu-west-1a,eu-west-1b INSTANCE INSTANCE-ID AVAILABILITY-ZONE STATE STATUS LAUNCH- CONFIG INSTANCE i-725b5205 eu-west-1b InService Healthy ActuatorLC Figur 126: Auto scaling groups defineret. Skalerings politikkerne eksekveres i Figur 127 og Figur 128 og verificeres i Figur 129 og Figur 130. as-execute-policy ActuatorPolicyUp --auto-scaling-group ActuatorGroup Resultat OK-Executed Policy Figur 127: Udførsel af scale up politik for Actuator auto scaling group. as-execute-policy ActuatorPolicyDown --auto-scaling-group ActuatorGroup Resultat OK-Executed Policy Figur 128: Udførsel af scale down politik for Actuator auto scaling group. as-describe-auto-scaling-groups headers Resultat AUTO-SCALING-GROUP GROUP-NAME LAUNCH-CONFIG AVAILABILITY-ZONES MIN-SIZE MAX-SIZE DESIRED-CAPACITY AUTO-SCALING-GROUP ActuatorGroup ActuatorLC eu-west-1a,eu-west-1b INSTANCE INSTANCE-ID AVAILABILITY-ZONE STATE STATUS LAUNCH-CONFIG INSTANCE i-725b5205 eu-west-1b InService Healthy ActuatorLC INSTANCE i-8c5a53fb eu-west-1a InService Healthy ActuatorLC Figur 129: Verifikation af udførsel af scaling up politik for Actuator autoscaling group. as-describe-auto-scaling-groups --headers Resultat AUTO-SCALING-GROUP GROUP-NAME LAUNCH-CONFIG AVAILABILITY-ZONES MIN-SIZE MAX-SIZE DESIRED-CAPACITY AUTO-SCALING-GROUP ActuatorGroup ActuatorLC eu-west-1a,eu-west-1b INSTANCE INSTANCE-ID AVAILABILITY-ZONE STATE STATUS LAUNCH-CONFIG INSTANCE i-8c5a53fb eu-west-1a InService Healthy ActuatorLC Figur 130: Verifikation af udførsel af scaling down politik for Actuator autoscaling group. Defintion af metrikker og alarmer i CloudWatch Auto scalerings politikker defineret for Actuator skal aktiveres af alarmer på høj og lav instans CPU forbrug. Associeringen mellem Auto scaling politikkerne bliver udført ved oprettelse af CPU metrik alarmer i Figur 131 og Figur 132. mon-put-metric-alarm ActuatorHighCPUAlarm --comparison-operator GreaterThanThreshold -- evaluation-periods 1 --metric-name CPUUtilization --namespace "AWS/EC2" --period 60 --unit Percent --statistic Average --threshold 80 --alarm-actions arn:aws:autoscaling:eu-west- 1: :scalingPolicy:94a1cbc4-d173-4f75-aa97- e5abed013d95:autoscalinggroupname/actuatorgroup:policyname/actuatorpolicyup Resultat OK-Created Alarm Figur 131: Oprettelse af CloudWatch alarm for høj CPU belastning og associering med Actuator scaling politikker. Side 134 af 159

135 mon-put-metric-alarm ActuatorLowCPUAlarm --comparison-operator LessThanThreshold -- evaluation-periods 1 --metric-name CPUUtilization --namespace "AWS/EC2" --period 60 --unit Percent --statistic Average --threshold 40 --alarm-actions arn:aws:autoscaling:eu-west- 1: :scalin gpolicy:94a1cbc4-d173-4f75-aa97- e5abed013d95:autoscalinggroupname/actuatorgroup:policyname/actuatorpolicydown Resultat OK-Created Alarm Figur 132: Oprettelse af CloudWatch alarm for lav CPU belastning og associering med Actuator scaling politikker. Verifikation af oprettelse af CloudWatch alarmer ses i Figur 133. mon-describe-alarms --headers Resultat ALARM STATE ALARM_ACTIONS NAMESPACE METRIC_NAME PERIOD STATISTIC EVAL_PERIODS COMPARISON THRESHOLD ActuatorHighCPUAlarm ALARM arn:aws:autoscalin...me/actuatorpolicyup AWS/EC2 CPUUtilization 60 Average 1 GreaterThanThreshold 80.0 ActuatorLowCPUAlarm OK arn:aws:autoscalin.../actuatorpolicydown AWS/EC2 CPUUtilization 60 Average 1 LessThanThreshold 40.0 Figur 133: Verifikation af CloudWatch alarmer for Actuator auto scaling gruppe. Tilknytning af notifikationer for Cloud Watch for alarmer Systemet skal være i stand til at modtage hændelser om alarmer, som aktiverer auto scaling politikker. Dette kan muliggøres ved at oprette et topic i Simple Notificatoin service, som CloudWatch kan sende alarmer til samtidig med alarmer sendes til auto scaling grupperne. Et topic oprettes et subsription tilknyttes CP09Mon køen, som Monitor komponenten overvåger. Dette er vist i Figur 134 og Figur 135. sns-create-topic --name cw-alarms-cp09-topic Resultat arn:aws:sns:eu-west-1: :cw-alarms-cp09-topic Figur 134: Oprettelse af CP09 CloudWatch topic. sns-subscribe arn:aws:sns:eu-west-1: :cw-alarms-cp09-topic --protocol sqs --endpoint arn:aws:sqs:eu-west-1: :cp09mon Resultat Subscription request received. Figur 135: Oprettelse af CP09 CloudWatch topic subscription. Subscription verificeres i Figur 136. sns-list-subscriptions Resultat arn:aws:sns:eu-west-1: :cw-alarms-cp09-topic:81fb8dd1-e8ba a4- a0ce515f9f10 sqs arn:aws:sqs:eu-west-1: :cp09mon Figur 136: Verifikation af SNS subscription. CloudWatch alarmer opdateres, således alarmer også sende til Monitor kø subscription, dette er vist i Figur 137 og Figur 138. mon-put-metric-alarm ActuatorHighCPUAlarm --comparison-operator GreaterThanThreshold -- evaluation-periods 1 --metric-name CPUUtilization --namespace "AWS/EC2" --period statistic Average --threshold 80 --alarm-actions arn:aws:autoscaling:eu-west- 1: :scalingPolicy:94a1cbc4-d173-4f75-aa97- e5abed013d95:autoscalinggroupname/actuatorgroup:policyname/actuatorpolicyup,arn:aws:sns: eu-west-1: :cw-alarms-cp09-topic Resultat Side 135 af 159

136 OK-Created Alarm Figur 137: Opdatering af CloudWatch alarm ved høj CPU belastning, således at alarmer bliver sendt som notifikatoiner via SNS til Monitor kø. mon-put-metric-alarm ActuatorLowCPUAlarm --comparison-operator LessThanThreshold -- evaluation-periods 1 --metric-name CPUUtilization --namespace "AWS/EC2" --period statistic Average --threshold 40 --alarm-actions arn:aws:autoscaling:eu-west- 1: :scalingPolicy:94a1cbc4-d173-4f75-aa97- e5abed013d95:autoscalinggroupname/actuatorgroup:policyname/actuatorpolicydown,arn:aws:s ns:eu-west-1: :cw-alarms-cp09-topic Resultat OK-Created Alarm Figur 138: Opdatering af CloudWatch alarm ved lav CPU belastning, således at alarmer bliver sendt som notifikatoiner via SNS til Monitor kø. Test Dette scenarie afslutter den sidste konfiguration af system i cloud platformen. Det samlede system kan hermed testes i sammenhæng. Der startes 2 instanser af Control og Sensor og Actuator på cloud platformen, som vist for Control i Figur 139. as-update-auto-scaling-group ControlGroup --min-size 2 --max-size 4 Resultat OK-Updated AutoScalingGroup Figur 139: Opstart af instanser i Control auto scaling group. Alle de instanser kørende på cloud platformen ses i Figur 140 og Monitor GUI visualierere resultatet i Figur 141 og Figur 142. as-describe-auto-scaling-groups headers Resultat AUTO-SCALING-GROUP ActuatorGroup ActuatorLC eu-west-1a,eu-west-1b INSTANCE i-c66f7cb1 eu-west-1a InService Healthy ActuatorLC INSTANCE i-c46f7cb3 eu-west-1b InService Healthy ActuatorLC AUTO-SCALING-GROUP ControlGroup ControlLC eu-west-1a,eu-west-1b INSTANCE i-966f7ce1 eu-west-1a Pending Healthy ControlLC INSTANCE i-946f7ce3 eu-west-1b Pending Healthy ControlLC AUTO-SCALING-GROUP SensorPairGroup SensorPairLC eu-west-1a,eu-west-1b INSTANCE i-ac6f7cdb eu-west-1b Pending Healthy SensorPairLC INSTANCE i-aa6f7cdd eu-west-1a Pending Healthy SensorPairLC Figur 140: Verifikation af opstart af alle CP09 system instanser. Side 136 af 159

137 Figur 141: Monitor GUI Status kontekst visualierer modtagne temperatur og tryk værdier, størrelsen på Monitor, Control og Actuator Blackboard køer samt system hændelser som f.eks. aktivering af auto scaling politikker og akrivering af aktuatorer. Side 137 af 159

138 Figur 142: Monitor GUI Config kontekst viser den de nuværende auto scaling grupper, launch grupper samt aktive instanser. Side 138 af 159

139 Konklusion Scenariet blev ikke udført indenfor tidsrammen på 7 timer pga. detalje studie af problem med aktivering af auto scaling politik for høj CPU belastning. Dette blev i scenariet simuleret ved at sende en specifik temperatur værdi på 2000, som Control fortolkede og sendte en CPULoad besked til Actuator. Efter Actuaor modtog denne besked fortsatte afviklingen i en uendelig løkke, som fik den virtuelle maskine CPU til at blive belastet. Dette blev verificeret af CloudWatch CPU metrik vha. AWS Management Console. Derfor kan problemet være relateret til CloudWatch alarmen for høj CPU belastning Konklusion Scenarierne målt på de definerede tidsmetrikker fejlede. Dette skyldes problemer i platformen, som skulle undersøges hvilket resulterede i, at aktiviteterne i scenarierne blev afbrudt. Problemerne blev identificeret til at være klassificeret til at være en del af leveret udviklingssoftware og selve platformen. Det første problem relateret til platformen og udviklingssoftware var konfiguration af adgangssystemet for de enkelte køer i platformen kø service. Dette skyldes en fortolknings fejl af den definerede adgangspolitik, som ikke understøttede deklareringen af en sammenlignings statement. Den efterfølgende fundne fejl var af en mere alvorlig karakter. Tidligt i det første scenarie rapporterede EC2 servicen fejl, når der blev for søgt at starte EC2 instanser i USA og APAC regionen. Da problemet blev undersøgt blev der fundet lignende problemer på AWS status site. Selvom problemet blev rapporteret til Amazon med en detaljeret beskrivelse, blev status overblikket ikke opdateret for tidspunktet, hvor problemet blev observeret. Da der blev undersøgt nærmere på fora om der fandtes lignende problemer, blev en løsning beskrevet, hvor en Auto Scaling group defineres til at starte EC2 instanser i flere regioners availability zones for dermed at sikre tilgængeligheden af ressourcerne. Denne taktik blev også anvendt under testen, em begge availability zones defineret for Auto Scaling gruppen fejlede. Det andet platform service orienteret problem, blev fundet i det sidste scenarie, da systemet var endelig designet og realiseret. Det lykkedes ikke, at aktiveret en CloudWatch alarm for metrikken CPU utilization, således skalering af flere EC2 instanser kunne demonstreres, når system bliver belastet. Modsat kunne CloudWatch alarmen for lav CPU belastning aktiveres og dette blev registreret i CP09 systemet Monitor GUI hændelse log. Subjektiv giver det umiddelbart indtryk af en umoden platform. Men der er også mange teknologi muligheder i platformen. For eksempel understøttes virtuelle maskiner med mange forskellige konfigurationer. Komponenter Side 139 af 159

140 eksisterer i platformen for at varetage elementer i den self managed autonomic computing arkitektur. Manager delen er delt mellem CloudWatch, Auto Scaling og EC2 service. CloudWatch har til ansvar at monitorere det managed element, EC2 service skal administrerer ressourcer og Auto Scaling skal udfører politikker. Det kunne være interessant med mulighed for definition af egne metrikker i CloudWatch, som der kan defineres politikker ud fra. Platformen anvender forskellige availability taktikker. For eksempel er platformen opdelt i zoner i regionen, hvor servicen findes. AWS har flere datacentrer i Europa, USA og Asien og brugeren har mulighed for at vælge, hvordan systemet skal udrulles for at opnå den bedst mulige tilgængelighed. Det kræver specifikke kvalitetskrav for en arkitektur anvendt til en cloud service, hvis denne skal udnyttes. For at systemet kan skalere skal der være lav kobling mellem services og de må gerne være uafhængige, hvis muligt. Dermed kan services, som afvikles på platformen, startes og stoppes uden af brugeren bemærker dette. Men der findes mange arkitekturer patterns, som har denne kvalitet, f.eks. Blackboard pattern anvendt i casen. 8 KONKLUSION Metoden og den tilhørende proces for projektet og rapporten har været formaliseret for hver enkelt aktivitet, der skulle udføres for at opnå resultatet og løse problemstillingen defineret. Dette har sikret en objektiv analyse af de 5 udvalgte teknologi kandidater og en balanceret sammenligning, da kandidaten til eksperimentet skulle findes. Dette er det andet rapport produkt baseret på denne metode og konklusion er lignende observationer fra tidligere rapport[12]. Processen kræver, at man afsætter tid til at studere den givne teknologi ellers kan man ikke svare på spørgsmålene, som metoden stiller, f.eks. anvendte prismodeller, teknologi sammensætning, dokumentation og lignende. Den ikke praksis orienteret del af processen bliver valideret i det efterfølgende eksperiment og her skal teknologien bevise, at funktionelle krav og kvalitets krav opfyldes. Resultaterne fundet i den teoretisk og praktiske del viser, at metoden kan anvendes til at synliggøre eventuelle svagheder i teknologien og informere en beslutning om teknologien skal vælges til f.eks. systemudvikling. Metoden og teknologien har givet mulighed for at arbejde med arkitektur design processen. Det viste sig, at den oprindelige broker baseret arkitektur ikke kunne anvendes direkte i platformen uden at foretage yderligere udvikling eller konfiguration. Observationen med dette arbejde er, at problemerne en arkitektur skal løse skal beskrives eksplicit, således den bedste style kan findes. Når en passende style er fundet kan de i omfang mindre design patterns anvendes til at løse problemer objekter eller klasser i mellem. Teknologi kandidaten blev evalueret i det tidligere afsnit ud fra de teoretiske og eksperiment praktiske perspektiver. Indtrykket, som Side 140 af 159

141 observationer også understøtter, er teknologien findes umoden med hensyn til tilgængelighed og udvikling understøttelse. Amazon giver dog mulighed for vha. detaljeret dokumentation, hyppige opdateringer af software, at finde løsninger på problemer. Platformen har potentiale i et autonomic computing perspektiv. Det kunne også være interessant at kombinere flere cloud teknologier (intercloud) for at dække svagheder mellem teknologierne. For eksempel, så har AWS ikke en service registry eller service til at hjælpe med komponeringen af services. Dette har Azure og man kan dermed kombinere dem. Teknologierne er desuden ikke gamle, den første frigivelse af AWS software fandt sted i 2006 for services og marts 2010 for Java SDK i version 1.0. Prisanalysen viser, at priserne for ressourcerne er meget tæt for cloud udbyderne der tilbyder lignede services f.eks. AWS og Azure. En sidste observation til rapporten er at der ikke findes en definition for begrebet Cloud computing, men flere. Dette giver det indtryk, at da brutto kandidat listen af teknologi produkt blev gennemgået producenter markedsfører produkter under begrebet uden at opfylde kravene til denne. Det er især et indtryk for traditionel hosting provider af server ressourcer, at disse kan benævne produktet cloud uden at have egenskaber som f.eks. auto scaling og en forbrugsafregnet prismodel. Side 141 af 159

142 REFERENCER 1. Synopsis Template, Henrik Bærbak Christensen, Autonomic Computing: IBM s Perspective on the State of Information Technology, IBM Research, P. Horn, puting.pdf 3. The Vision of Autonomic Computing, IEEE Computer, J. Kephart and D. Chess,Vol. 36, No. 1, 2003, n_computer_jan_2003.pdf 4. An Architectural Approach to Autonomic Computing, IBM Research, White et. al., An architectural blueprint for autonomic computing, Whitepaper, IBM, Software Architecture in Practice 2nd Ed, Bass, Clements, and Kazman, Addison-Wesley, Market-Oriented Cloud Computing: Vision, Hype, and Reality for Delivering IT Services as Computing Utilities, Buyya et. al., Proceedings of the th IEEE International Conference on High Performance Computing and Communications, Monitor and control system for a chemincal plant, CP09, kravsbeskrivelse, Henrik Bærbak Christensen, Monitor and control system for a chemincal plant, CP09 opgavebeskrivelse, Henrik Bærbak Christensen, An Approach to Software Architecture Description Using UML Revision 2.0, Henrik Bærbak Christensen et al., University of Aarhus, Computer science, Kritiske systemer, Overvågning og kontrol system for et kemisk produktions anlæg CP09, Thomas Mollerup Lanng, Michael Brøbech Mogensen, 03. december, 2009, googlecode.com/svn/reliable%20architecture/docs/exercise%2 04/R05.pdf 12. Evaluering af udbud og modenhed af self managed arkitektur software teknologier, Thomas Mollerup Lanng, Michael Brøbech Mogensen, 2010, googlecode.com/svn/RSA_Project/docs/R05.pdf 13. Google Sites, Google Code, Virtual Machine Monitors: Current Technology and Future Trends, Garfinkel et al., IEEE, The Architecture of Virtual Machines, James E. Smith og Ravi Nair, IEEE, 2005 Side 142 af 159

143 17. Toward a Unified Ontology of Cloud Computing, Youseff et al., University of California, Grid Computing Environments Workshop, A taxonomy and survey of cloud computing systems, Rimal et al., University og Kookmin, Fifth International Joint Conference on INC, IMS and IDC, What s Inside the Cloud? An Architectural Map of the Cloud Landscape, Lenk et al., FZI Karlsruhe, CLOUD '09 Proceedings of the 2009 ICSE Workshop on Software Engineering Challenges of Cloud Computing, Is Cloud Computing Ready For The Enterprise?, Staten et al., Forrester Research, Outsourcing Business to Cloud Computing Services: Opportunities and Challenges, Motahari-Nezhad et al., HP Laboratories, A Tale of Clouds: Paradigm Comparisons and Some Thoughts on Research Issues, Mei et al., University of Hong Kong, Proceedings of the 2008 IEEE Asia-Pacific Services Computing Conference (APSCC 2008), IEEE Computer Society Press, Cloud computing, Wikipedia, Twenty-One Experts Define Cloud Computing, Cloud Computing Journal, Geelan, 2009, Cloud Computing and Emerging IT Platforms: Vision, Hype, and Reality for Delivering Computing as the 5th Utility, Buyya et al., University of Melbourne, Survey of Frameworks, Architectures and Techniques in Autonomic Computing, Amina Khalid, Mouna Abdul Haye, Malik Jahan Khan, Shafay Shamail, Lahore University, Side 143 af 159

144 Microsoft Azure, Microsoft Azure, Whitepaper, Introducing Windows Azure, David Chappell, oktober, 2010, Microsoft Azure, Whitepaper, Introducing The Windows Azure Platform, David Chappell, december, 2009, re_platform_v1.3--chappell.pdf 51. Microsoft Azure, Portal, Microsoft Azure Service Level Agreement (SLA), An Introduction to Windows Azure platform AppFabric for Developers, Aaron Skonnard, Keith Brown, Pluralsight, November 2009, Open Data Protocol, Atom Publishing Protocol, Security Assetion Markup Language, Microsoft Azure prismodel, Microsoft Azure instans type beskrivelser, Microsoft Azure interoperabilitet, Microsoft Azure Service Dashboard, board.aspx 61. Microsoft Azure SDK, Microsoft Azure opdateringer, Windows Azure Security Overview, Charlie Kaufman, Ramanathan Venkatapathy, August 2010, Microsoft Azure datacentrer, The Windows Azure Platform: A Perspective, David Chappell, Chappell & Associates, Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic MapReduce, Amazon Auto Scaling, Amazon Elastic Load Balancing, Amazon SimpleDB, Amazon Elastic Block Store (EBS), Side 144 af 159

145 72. Amazon Simple Storage Service (Amazon S3), Amazon Relational Database Service (Amazon RDS), Amazon Simple Queue Service (Amazon SQS), Amazon CloudFront, AWS Import/Export, Amazon Simple Notification Service (Amazon SNS), Amazon Web Services Mangement Console, Amazon Web Services service health Dashboard, Amazon CloudWatch, Amazon Mechanical Turk, Amazon Route 53, Amazon Virtual Private Cloud (Amazon VPC), Amazon Fulfillment Web Service (Amazon FWS), Amazon Flexible Payments Service (Amazon FPS), Amazon DevPay, Alexa Web Information Service, Alexa Top Sites, Amazon Identity and Access Management (IAM), Amazon Web Services dokumentation, Amazon Web Services Overview, Web Services Description Language (WSDL), Web Services Architecture, Amazon EC2 Service Level Agreement, sla 95. Amazon Machine Images (AMI), Amazon EC2 type beskrivelser, Amazon EC2 priser, Amazon platform beskrivelse, Amazon Machine Images katalog, AWS Java tool kit versionshistorik, Side 145 af 159

146 101. AWS EC2 releases, TF8&jiveRedirect= AWS sikkerhed, App Engine dokumentation, Google App Engine, The Windows Azure Platform: A Perspective, David Chappell, Chappell & Associates, App Engine Java Overview, App Engine Java Datastore, App Engine Java High Replication Datastore, Paxos Made Live - An Engineering Perspective, Tushar Chandra et al., 2007, labs.google.com/en//papers/paxos_made_live.pdf 110. App Engine Java Blobstore, l 111. App Engine Java Channel, App Engine Java Images, App Engine Java Mail, App Engine Java Memcache, ml 115. App Engine Java Multitenancy. html 116. App Engine Java OAuth, App Engine Java Task Queues, ml 118. App Engine Java Scheduled Tasks, App Engine Java URL Fetch, App Engine Java Users, App Engine Java XMPP, Side 146 af 159

147 122. App Engine Services Javadoc, App Engine Portal, App Engine betalingsmodel, App Engine For Business Preview bestailingsmodel, App Engine For Business Preview SLA, App Engine Roadmap, App Engine revision history, App Engine release notes, Java SDK, Notes 130. App Engine system status, App Engine open issues tracker, The Architecture of Virtual Machines, James E. Smith og Ravi Nair, IEEE, Extensible Messaging and Presence Protocol, DoS protection service, App Engine Quotas, App Engine instanser, Heroku overview, Heroku arkitektur, Heroku Dyno overview, Heroku Dyno, Heroku HTTP cache, Heroku Rack based applications, Background jobs / workers and job queues, Heroku Slug compiler, Heroku SQL database, Heroku platform stacks, Heroku release management, Heroku maintenance mode, Heroku Bundles, Heroku addons, Heroku betalingsmodel, Heroku versioner, Side 147 af 159

148 153. Heroku pressemeddelelse, opkøbt af Salesforce.com inc., Heroku beskrivelse, Versionsstyrings værktøj Git, Udviklingssprog Ruby, Heroku management Ruby applikation, Heroku anvendelse af Amazon platform, Heroku service status, Heroku addons, Heroku sikkerhedsbeskrivelse, Joyent Smart teknologi overview, Joyent SmartPlatform, Joyent SmartMachines, Joyent SmartOS SmartMachine, Joyent SmartDataCenter, The Joyent Smart Technologies Architecture for Cloud Computing, content/uploads/2010/05/joyent-smart-architecture-for-cloud- Computing.pdf 168. Joyent Scale Architectures, Joyent betalingsmodel, Joyent services og betailngsmodel, SmartMachine typer, betalingsmodel og SLA, SmartMachine software, Joyent hardware specifkationer, services, software teknologi support, conformance og geografisk lokation af data centrer, Developers introduction to the Java script SmartPlatform, Joyent Cloud Hosting Service Level Agreement, Side 148 af 159

149 176. Joyent Safe Harbor Principles, Joyent wiki, XEN projekt, Advanced Message Queuing Protocol, Extensible Messaging and Presence Protocol, AWS account oprettelse, AWS EC2 service oprettelse, AWS Management Console, AWS service account, AWS sikkerheds credentials, boutawscredentials.html#quickstart 186. AWS sikkerhedsgrupper, AWS SDK til Java, AWS udviklings API services værktøjer, EC2 API tool, AutoScaling API tool, CloudWatch API tool, SNS API tool, AWS Toolkit til Eclipse, AWS Getting Started with Amazon EC2 Management in Eclipse, Pattern-oriented software architecture A system of patterns, Volume 1, Buschmann et al., John Wiley and Sons Ltd., Software Architecture in Practice 2nd Ed, Bass, Clements, and Kazman, Addison-Wesley, Software Engineering 7th Ed", Sommerville, Addison-Wesley, Amazon Simple Queue Service, Developer Guide, API Version , 01.pdf 199. SQS policy problem, Amazon Elastic Compute Cloud, User Guide, API Version , ug.pdf 201. AWS Auto Scaling, Developer Guide, API Version , Side 149 af 159

150 202. Amazon CloudWatch, Developer Guide, API Version , EC2, Developer Guide, Side 150 af 159

151 TIDSPLAN Exam Final hand in of report. Problemformulering Afsluttet Teori Afsluttet Case Afsluttet Usability scenarios Afsluttet definitioner Usability scenarios Afsluttet Samling af rapport Afsluttet Konklusion Afsluttet Rapport gennemlæsning og Afsluttet korrektion og forberedelse af kode Aflevering af rapport og Afsluttet kode med credendials filer (access keys, X.509 certificates og key pairs) Supervisor feedback Status og rapport send til Afsluttet HBC Layout ændringer Afsluttet skriftstørrelse 10pkt for captions og tabeller Referencer opdateres Afsluttet Form og struktur Afsluttet koordineres i teknologi kandidater evalueringsafsnit Resterende elementer Afsluttet udfyldes i teknologi kandidater evalueringsafsnit Teoriafsnit afsluttes Afsluttet Supervisor feedback Status sendt til HBC Afsluttet Gennemlæsning af seneste rapport ændringer forsøges gennemført af HBC senere, da afleveringsdato blev overskrevet p.g.a. TML sygdom Supervisor feedback Status sendt til HBC Afsluttet Update og indsæt referencer Afsluttet i teori og metode afsnit (kvalitetsattribut scenarier) Supervisor feedback Indførsel af rettelser ref. Afsluttet HBC kommentarer samt AU forside. Side 151 af 159

152 Ændringer til rapporten beskrevet til HBC: - Indledning, Motvation, Problemformulering - Metode beskrevet - Kandidater udvalgt (første udgave) Spørgsmål HBC ang. til betaling af kandidater til afprøvning Afsluttet Afsluttet Supervisor feedback Afsluttet Aflevering af synopsis til godkendelse (inkl. Afsluttet Problemformulering og synopsis godkendt. indledning, motivation, problemformulering, tidsplan) Rapport forside Afsluttet sendt til Marianne Dammand Thesis kickoff meeting - Afsluttet AU Introduktion af speciale Afsluttet forløb Valg af speciale emne Afsluttet Præsentation af 4 emner indenfor : 1. Arkitektur evaluering 2. Udviklingsmodeller 3. Virtualiering og autonomic computing 4. Vidensdeling Udarbejdelse af første udgave af problemformulering / hypotese Afsluttet Evaluering af udbud og modenhed af cloud computing teknologier, der understøtter autonom computing teorien Tildeling af vejleder Afsluttet HBC valgt som vejleder indenfor området Cloud computing Side 152 af 159

153 APPENDIKS: EC2 FEJL FUNDET VED TEST Alle regions(us, EU og APAC) og availability zones gennemgået den 15/ Fejl på regionerne: - US, availability zones (us-east-1a, us-west-1c) - APAC, availability zones (ap-southeast-1a, ap-southeast-1b) Bemærk viste ingen problemer selvom status er 14/12 (US 6-7 timer bagefter DK) Historikken for regionerne viser problemer registreret for EC2: - US, availability zone us-east-1, den 10. december 2010 og - EU, availability zone us-west-1, den 12. december 2010 Opdatering: den 16. december 2010 kan - us-west-1c, - ap-southeast-1a og - ap-southeast-1b oprettes Side 153 af 159

154 Side 154 af 159

155 Side 155 af 159

156 Oprettelse af instans Side 156 af 159

157 Side 157 af 159