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 Virtualization (opdater) Fremtiden Reliability from virtualization Cloud computing (Opdater) Cloud computing åbenhed Cloud computing pris modeller Cloud computing og self managed arkitekturer analyse produkt? (opdater) Kvalitetsattribut scenarier Metode Projektfaser Foranalyse Eksperiment Og Evaluering Kvalitetsattribut Scenarier Scenarie 1: Opsætning af udviklingsmiljø Scenarie 2: Udvikling af første services Scenarie 3: Tilvejebringelse af services Scenarie 4: Overvågning og SLA Scenarie 5: Test Evalueringstaksonomi Analyse Og Resultater Foranalyse Kandidater Evaluering Microsoft Azure Amazon EC Google App Engine Heroku Joyent Konklusion Eksperiment Case beskrivelse Design Implementering Test Evaluering Scenarie 1: Opsætning af udviklingsmiljø Side 2 af 87

3 7.3.2 Scenarie 2: Udvikling af første services Scenarie 3: Tilvejebringelse af services Scenarie 4: Overvågning og SLA Scenarie 5: Test Konklusion Samlet evaluering Konklusion Referencer Tidsplan... 86

4 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 et 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 4 af 87

5 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, Buyva [7], Java teknologier, der understøtter autonom computing teorien, som defineret af Kephart et. al. [3] og White et. al. [4]. Processen er opdelt i en foranalyse fase, hvori der udvælges en teknologi kandidat, til den eksperimentelle fase. Erfaringerne fra eksperimenterne indgår i yderligere evaluering ud fra et praktisk perspektiv. 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 følgende kriterier: Hvor godt understøttes teorien? Hvor svært er det (at komme i gang med) at bruge? Hvor god er eksempler/dokumentation? Hvor mange versioner / releases og hvor ofte udgives nyt? Hvor mange anslåede brugere? Side 5 af 87

6 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[32] Subversion repository. Side 6 af 87

7 5 TEORI Emner (overvej sortering af emner) 1. Virtualiering (hoved teknologi for cloud computing, muliggør ressource opdeling, quality of service Qos) 2. Autonmic computing, principper, self managed arkitektur krav, modenheds evolution (IBM blueprint - modenhedsniveauer) 3. Kvalitetsattribut scenarier til beskrivelse af brugbarhed af teknologier 4. Definition af cloud computing også i et historisk perspektiv andre computing koncepter f.eks. autonomic computing a. Computing paradigmer i et historisk perspektiv (buyya) b. Klassificering af Cloud computing platforme, Paas, SaaS.. c. Global Cloud børs og markeder og krav til modenhed af cloud computing d. Til evaluering kvalitativ sammenligning af autonomic computing self managed arkitektur krav og global cloud børs og markeder krav arbejdsprodukt ift. problemformulering e. Cloud åbenhed og standarder f. Cloud pris modeller Side 7 af 87

8 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 opgave anvendes viewpoints: component & connector, module og deployment. Figur 1: Ontologi af en arkitektur beskrivelse, opgave anvendte views er markeret rødt [28]. Component & connector viewpoint [28]: elementer består af komponenter (component) og relationer af forbindelser (connector) mellem disse, hvor komponenten indeholder funktionalitet og et veldefineret ansvar eller rolle og forbindelser er, beskriver kommunikationen mellem komponenterne (herunder kontrol og data). Deployment viewpoint [28]: elementer består af software elementer, som kan være eksekverbare(executables) eller link libraries indeholdende komponenter, fra component & connector view og miljø elementer som er knuder (nodes) af computer hardware. Relationer består af følgende type: - allocated-to, som henviser til hvilke miljøer elementer, som de enkelte software elementer er allokeret til - afhængigheder mellem software elementer - protokol forbindelser (links) mellem miljø elementer, som viser, hvilken kommunikations protokol anvendt mellem knuderne. Side 8 af 87

9 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. Til at i møde komme 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ø. 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] forslå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 Side 9 af 87

10 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. 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. Denne kravsliste 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 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 Side 10 af 87

11 KO.17 KO.18 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 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 realisere interfaces for at opnå self management System sammensætning Monitoring og test interfaces Lifecycle interfaces KI.2 KI.3 KI.4 KI.5 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 Side 11 af 87

12 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 - 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. 5.3 VIRTUALIZATION (OPDATER) Definition virtual: existing in essence or effect, though not in actual fact Definition på fysisk maskine: Hardware: processor, ram, disk Software: bygget til hardware, f.eks. o X86, instuktionssæt arkitektur (ISA=Instruction Set Architecture) o OS, f.eks. Windows / Linux, OS kontrollere hardware. Side 12 af 87

13 Virtuel maskine Hardware abstractionslag med virtuelle processorer, ram og andre enheder Virtualiseringssoftware der afkobler hardware og software og multiplekser fysisk hardware i mellem forskellige virtuelle maskiner. Fordele o Udnyttelse af ressourcer o Isolation, crash isoleres i den aktuelle VM (virus) o Inkapsling, vm er en fil, der er let at kopiere og distribuere o Recovery points ud over hvad der understøttes i OS o Migrering til anden fysisk maskine o Økonomi, det er nemmere at vedligeholde én VM platform frem for 100 fysiske maskiner. o Create once, run anywhere Legacy VM o F.eks. ScummVM Java VM Side 13 af 87

14 Klassifikation af VM ISA: x86, RISC, PowerPC The process VM puts the virtualization border line at the process line. A application process/program o executes in a Logical address space (assigned/handled by the OS) o Using user-level instructions and registers (CPU user-mode) o Only do IO using OS calls or High-Level Library(HHL) calls Side 14 af 87

15 Thus a process VM becomes a virtual OS in which a process may execute. Example: Different ISA Process VM o JavaVM defines its own ISA (stack-based) as well as normal OS operations The system VM sets the virtualization border at the system or hardware line A system/os executes in a o Physical memory space o Using the full ISA of the underlying machine o Interact directly with IO Thus a system VM becomes a virtual machine in which a system as a whole may execute Example: Same ISA System VM: VMWare: Executes Guest OS that is running on the x86 ISA. VirtualPC running Windows on Mac I praksis A CPU architecture is virtualizable if it supports the basic VMM technique of direct execution executing the virtual machine on the real machine, while letting the VMM retain ultimate control of the CPU. X86 arkitektur. Ring 0 kan man gøre alt incl. Tilgå memory management, hardware. OS kører normalt her. Ring 1+2 device driveres Ring 3+ bruger programmer, kan fejle uden at påvirke systemet som helhed. Bruger programmer må gå via OS for at tilgå hardware. If VMWare is an app, running in Windows, and it runs the Linux OS inside, it follows that - Privileged instructions have to run in usermode! VVM: Virtual Machine Monitor o VVM runs in priviledged mode o All inside runs in user mode So what can we do about that? Side 15 af 87

16 o Emulation o Trap-and-Emulate o Binary Translation Håndtering af instruktioner der ikke kan trappes Para virtualization = replacing non-virtualizable portions of the original instruction set with easily virtualizable and more efficient equivalents. o OS code has to be ported! (POPF erstattes af noget andet) o User apps run unmodified Binary translation o For each instruction classify Identicals instructions without problems : copy directly to translation cache (TC) Inline : replace instruction by inline equivalent instructions and copy these to TC Callouts : replace instruction by call to emulation code in VMM Let CPU execute contents of translation cache instead of original block Fremtiden Modern/Future CPU architectures Make a CPU with a Ring -1 VMM runs in Ring -1, and can run the OS in Ring 0. Recent CPUs from Intel and AMD offer x86 virtualization instructions for a hypervisor to control Ring 0 hardware access. [ ] a guest operating system can run Ring 0 operations natively without affecting other guests or the host OS. Side 16 af 87

17 5.3.2 Reliability from virtualization Fault avoidancy: nothing here, kun statiske værktøjer kan afhjælpe med at undgå fejl Fault detection and removal: o VM kan bruges til konfigurationstest (browser, OS), o Reproducere fejl i helpdesk o Record and playback o Virtuelle netværk + netværksudstyr kan afhjælpe test af overbelastet netværk. Fault tolerance o Backward recovery (gendanne system fra snapshot) o I tilfælde af hardwarefejl kan kørende VMer migreres til anden fysisk maskine evt. med software overvågning. o Hot standby o Load balancing ved oprette og nedlægge VMer Side 17 af 87

18 5.4 CLOUD COMPUTING (OPDATER) Cloud defintion Karateristika: Se også Open Cloud manifesto (whitepaper) for definition af Cloud og taksenomi Def. 1 Def. 2 Def- 3 "A Cloud is a type of parallel and distributed system consisting of a collection of interconnected and virtualized computers that are dynamically provisioned and presented as one or more unified computing resource(s) based on service-level agreements established through negotiation between the service provider and consumers. Cloud computing is Internet-based computing, whereby shared resources, software, and information are provided to computers and other devices on demand, like the electricity grid. Side 18 af 87

19 Taksonomi Se også Open Cloud manifesto (whitepaper) for definition af Cloud og taksenomi Figur 2: Cloud arkitektur Side 19 af 87

20 Taksonomi Service Def. 1 Def. 2 Def. 3 Def. 4 Infrastructure as a Service (IaaS) On the lowest level of the infrastructure closest to the hardware we distinguish two types of services, Physical Resource Set (PRS) and Virtual Resource Set (VRS) services. Both of these service types provide a management front-end API for a set or pool of resources in order to allow higher level services to automate setup and teardown, demand based scalability, fail-over and operating system hosting. Primary functionality includes starting and stopping individual resources, OS imaging, network topology setup and capacity configuration. The PRS layer implementation is hardware dependent and therefore tied to a hardware vendor, whereas the VRS layer can be built on vendor independent hypervisor technology such as Xen [14] or on top of a PRS service to run in multi-vendor Clouds such as the Open Cirrus testbed. Examples of PRS services include, Emulab [33] and ilo [32]. VRS services include Amazon EC2 [4], Eucalyptus [43], Tycoon [37], Nimbus [36], and OpenNebula [53]. The reason to split these Resource Set (RS) services into two types allows automated management of physical as well as virtual resources. Furthermote some Cloud applications may incur too much overhead from running on a hypervisor butmight still want to use similar automated management capabilities offered by virtual delivers computer infrastructure - typically a platform virtualization environment - as a service. Rather than purchasing servers, software, data-center space or network equipment, clients instead buy those resources as a fully outsourced service. Suppliers typically bill such services on a utility computing basis and amount of resources consumed (and therefore the cost) will typically reflect the level of activity. IaaS evolved from virtual private server offerings.[57] Delivery of computer infrastructure as a service. Aside from the higher flexibility, a key benefit of IaaS is the usage-based payment scheme. This allows customers to pay as they grow. Another important advantage is that by always using the latest technology customers can achieve a much faster service delivery and time to market. Key examples are GoGrid, Flexiscale, Layered Technologies, Joyent and Mosso/Rackspace. Side 20 af 87

21 Platform as a Service (PaaS) machine monitors (VMMs) and VMM management toolkits such as the VRS examples given. Another reason for demarcation is that different types of resources such as storage, network and compute node resources might need to be virtualized in different ways. However, they might still be able to have a common PRS interface. One level higher up in the stack but still in the IaaS category we distinguish three types of Basic Infrastructure Services (BIS), computational, storage, and network. Some examples are MapReduce [11] (computational), GoogleFS [52] (storage), and OpenFlow [39] (network). As the highest level in the IaaS stack we consider Higher Infrastructure Services (HIS). Amazon s Dynamo [22], and Google s Bigtable [17] all fall into this category as they are typically built on top of BIS tools. Moving up to the PaaS level of our integrated stack we categorize the services into Programming Environments and Execution Environments. Example of the former is Sun s project Caroline [42] and the Django framework [13], and examples of the latter are Google s App Engine [24], Joyent s Reasonably Smart [34] and Microsoft s Azure [40]. As seen by these examples an Execution Environment PaaS typically also encompasses a Programming Environment PaaS. You could potentially replace the Django framework in deliver a computing platform and/or solution stack as a service, often consuming cloud infrastructure and sustaining cloud applications.[54] It facilitates deployment of applications without the cost and complexity of buying and managing the underlying hardware and software layers.[55] [56] It is the big idea to provide developers with a platform including all the systems and environments comprising the endto-end life cycle of developing, testing, deploying and hosting of sophisticated web application as a service delivered by a cloud based, a Platform-as-a-Service (PaaS). Key examples are GAE, Microsofs s Azure etc. Compared with conventional application development, this strategy can slash development time, offer hundreds of readily available tools and services, and quickly scale. Side 21 af 87

22 Software as a Service (SaaS) Human as a Service HuaaS Google App Engine with your own Programming Environment and Microsoft Azure offers a wide range of alternative programming tools under the Azure runtime umbrella. This decoupling between execution and development environments is thus represented by having two categories in our stack model. All the applications that run on the Cloud and provide a direct service to the customer are located in the SaaS layer. The application developers can either use the PaaS layer to develop and run their applications or directly use the IaaS infrastructure. Here we distinguish between Basic Application Services and Composite Application Services. Examples of Basic Application Services are the OpenId [46] and Google Maps [26] services. In the Composite Application Service category we have the mash-up support systems with Opensocial as the prominent example allowing entire social networks likemyspace to be used as Basic Services. We categorize Basic and Composite services into Application Services, which comprise the highest level building blocks for end-user applications running in the Cloud, such as Google Docs [25], Microsoft s Office Live [41] and OpenSocial mash-ups such as Auciti s Hangout [54]. Some services rely on massive-scale aggregation and extraction of information from crowds of people. Each individual deliver software as a service over the Internet, eliminating the need to install and run the application on the customer's own computers and simplifying maintenance and support. People tend to use the terms SaaS and cloud interchangeably, when in fact they are 2 different things.[52] Key characteristics include:[53] Network-based access to, and management of, commercially available (i.e., not custom) software Activities that are managed from central locations rather than at each customer's site, enabling customers to access applications remotely via the Web Application delivery that typically is closer to a one-to-many model (single instance, multi-tenant architecture) than to a one-to-one model, including architecture, pricing, partnering, and management characteristics Centralized feature updating, which obviates the need for downloadable patches and upgrades. Software as a Service is a multi-tenant platform. It uses common resources and a single instance of both the object ode of an application as well as the underlying database to support multiple customers simultaneously. SaaS commonly referred to as the Application Service Provider (ASP) model, is heralded by many as the new wave in application software distribution. Examples of the key providers are SalesForce.com (SFDC), NetSuite, Oracle, IBM and Microsoft etc. Side 22 af 87

23 Hardware as a Service (HaaS) in the crowd may use whatever technology or tools he or she see fit to solve the task. We call this top-most layer in our stack Human as a Service (HuaaS). In some cases human intelligence is used to contribute arbitrary services, such as newsworthy video streams (YouTube [58]), or ondemand subtask solutions (Amazon Mechanical Turk [3]). In our stack, these tools belong to the Crowdsourcing (CS) category. Some human intelligence aggregation services are more controlled and more targeted at predicting events or promoting popular ideas. Examples include the Iowa Electronic Markets [9], which are mainly used to predict outcomes of political races, and Digg [12], which is used to promote popular news. We call this latter category of services Information Aggregation Services (IAS), since they all aim at producing a single aggregate number representing the popular opinion of the crowd in various ways, for example using market mechanisms. According to Nicholas Carr [18], the idea of buying IT hardware or even an entire datacenter as a pay-as-you-go subscription service that scales up or down to meet your needs. But as a result of rapid advances in hardware virtualization, IT automation, and usage metering and pricing, I think the concept of hardware-as-a-service let s call it HaaS may at least be ready for prime time. This model is advantageous to the Side 23 af 87

24 enterprise users, since they do not need to invest in building and managing data centers. Udrulning/ deployment Se også Open Cloud manifesto (whitepaper) for definition af Cloud og taksonomi Private Public Hybrid Deployment Def. 1 Def. 2 Def. 2 Private The concept of a Private Computer Utility was first described by Douglas Parkhill in his 1966 book "The Challenge of the Computer Utility". The idea was based upon direct comparison with other industries (e.g. the electricity industry) and the extensive use of hybrid supply models to balance and mitigate risks. Private cloud and internal cloud have been described as neologisms, however the concepts themselves pre-date the term cloud by 40 years. Even within modern utility industries, hybrid models still exist despite the formation of reasonably well functioning markets and the ability to combine multiple providers. Some vendors have used the terms to describe offerings that emulate cloud computing on private networks. These (typically virtualisation Data and processes are manged within the organization without the restrictioins of network bandwidth, security exposures and legal requirements that using public cloud service across open, public networks might entail Side 24 af 87

25 Public Hybrid automation) products offer the ability to deliver some benefits of cloud computing whilst mitigating some of the pitfalls. These offerings capitalise on data security, corporate governance, and reliability concerns during this time of transition from a product to a functioning service based industry supported by competitive marketplaces. They have been criticized on the basis that users "still have to buy, build, and manage them" and as such do not benefit from lower upfront capital costs and less hands-on management,[63] essentially "[lacking] the economic model that makes cloud computing such an intriguing concept".[65] [66] describes cloud computing in the traditional mainstream sense, whereby resources are dynamically provisioned on a fine-grained, selfservice basis over the Internet, via web applications/web services, from an off-site third-party provider who bills on a fine-grained utility computing basis.[38] A hybrid cloud environment consisting of multiple internal and/or external providers[62] "will be typical for most enterprises".[63] By integrating multiple cloud services users may be able to ease the transition to public cloud services while avoiding issues such as PCI compliance.[64] Another perspective on deploying a web application in the cloud is using Hybrid Web Hosting, where the hosting infrastructure is a mix between Cloud Hosting for the web server, and Managed dedicated server for the database It describes the cloud computing in the traditional mainstraim sense, whereby resources are dynmaically provisioned on a finegrained, self-service, from an off-site thirdparty provider who shares resources The enviroment is consisting of multiple internal and or external proiders Side 25 af 87

26 Intercloud server. The Intercloud[67] is an interconnected global "cloud of clouds"[68] [69] and an extension of the Internet "network of networks" on which it is based.[70] The term was first used in the context of cloud computing in 2007 when Kevin Kelly stated that "eventually we'll have the intercloud, the cloud of clouds. This Intercloud will have the dimensions of one machine comprising all servers and attendant cloudbooks on the planet.".[68] It became popular in 2009[71] and has also been used to describe the datacenter of the future.[72] The Intercloud scenario is based on the key concept that each single cloud does not have infinite physical resources. If a cloud saturates the computational and storage resources of its virtualization infrastructure, it could not be able to satisfy further requests for service allocations sent from its clients. The Intercloud scenario aims to address such situation, and in theory, each cloud can use the computational and storage resources of the virtualization infrastructures of other clouds. Such form of pay-for-use may introduce new business opportunities among cloud providers if they manage to go beyond theoretical framework. Nevertheless, the Intercloud raises many more challenges than solutions concerning cloud federation, security, interoperability, QoS, vendor's lock-ins, trust, legal issues, monitoring and billing. The concept of a competitive utility computing market which combined many computer utilities Side 26 af 87

27 Community together was originally described by Douglas Parkhill in his 1966 book, the "Challenge of the Computer Utility". This concept has been subsequently used many times over the last 40 years and is identical to the Intercloud. A community cloud may be established where several organizations have similar requirements and seek to share infrastructure so as to realize some of the benefits of cloud computing. With the costs spread over fewer users than a public cloud (but more than a single tenant) this option is more expensive but may offer a higher level of privacy, security and/or policy compliance. Examples of community cloud include Google's "Gov Cloud".[61] Figur 3: Markeds orienteret cloud arkitektur. Side 27 af 87

28 Element Users/Brokers: Users or brokers acting on their behalf submit service requests from anywhere in the world to the Data Center and Cloud to be processed. SLA Resource Allocator: The SLA Resource Allocator acts as the interface between the Data Center/Cloud service provider and external users/brokers. It requires the interaction of the following mechanisms to support SLA-oriented resource management VMs: Multiple VMs can be started and stopped dynamically on a single physical machine to meet accepted service requests, hence providing maximum flexibility to configure various partitions of resources on the same physical machine to different specific requirements of service requests. In addition, multiple VMs can concurrently run applications based on different operating system environments on a single physical Krav - Service Request Examiner and Admission Control: When a service request is first submitted, the Service Request Examiner and Admission Control mechanism interprets the submitted request for QoS requirements before determining whether to accept or reject the request. Thus, it ensures that there is no overloading of resources whereby many service requests cannot be fulfilled successfully due to limited resources available. It also needs the latest status information regarding resource availability (from VM Monitor mechanism) and workload processing (from Service Request Monitor mechanism) in order to make resource allocation decisions effectively. Then, it assigns requests to VMs and determines resource entitlements for allocated VMs - Pricing: The Pricing mechanism decides how service requests are charged. For instance, requests can be charged based on submission time (peak/off-peak), pricing rates (fixed/changing) or availability of resources (supply/demand). Pricing serves as a basis for managing the supply and demand of computing resources within the Data Center and facilitates in prioritizing resource allocations effectively. - Accounting: The Accounting mechanism maintains the actual usage of resources by requests so that the final cost can be computed and charged to the users. In addition, the maintained historical usage information can be utilized by the Service Request Examiner and Admission Control mechanism to improve resource allocation decisions - VM Monitor: The VM Monitor mechanism keeps track of the availability of VMs and their resource entitlements. - Dispatcher: The Dispatcher mechanism starts the execution of accepted service requests on allocated VMs. - Service Request Monitor: The Service Request Monitor mechanism keeps track of the execution progress of service requests. Side 28 af 87

29 machine since every VM is completely isolated from one another on the same physical machine. Physical Machines: The Data Center comprises multiple computing servers that provide resources to meet service demands. QoS Commercial offerings of market-oriented Clouds must be able to: QoS parameters to consider in a service request, such as time, cost, reliability and trust/security. In particular, QoS requirements cannot be static and need to be dynamically updated over time due to continuing changes in business operations and operating environments. In short, there should be greater importance on customers since they pay for accessing services in Clouds. - support customer-driven service management based on customer profiles and requested service requirements, - define computational risk management tactics to identify, assess, and manage risks involved in the execution of applications with regards to service requirements and customer needs, - derive appropriate market-based resource management strategies that encompass both customer-driven service management and computational risk management to sustain SLA-oriented resource allocation, - incorporate autonomic resource management models that effectively self-manage changes in service requirements to satisfy both new service demands and existing service obligations, and - leverage VM technology to dynamically assign resource shares according to service requirements. Tabel 2: Cloud børs arkitektur krav []. Figur 4: Global cloud børs. Element services follow standard interfaces Krav For Cloud computing to mature, it is required that the services follow standard interfaces. This would enable services to be commoditised and thus, would pave the way for the creation of a market infrastructure for trading in services. An example of such a market system, modeled on real-world exchanges, is shown in Figure 4. The market directory allows participants to Side 29 af 87

30 locate providers or consumers with the right offers. Auctioneers periodically clear bids and asks received from market participants. The banking system ensures that financial transactions pertaining to agreements between participants are carried out. Brokers Brokers perform the same function in such a market as they do in real-world markets: they mediate between consumers and providers by buying capacity from the provider and sub-leasing these to the consumers. A broker can accept requests from many users who have a choice of submitting their requirements to different brokers. Consumers, brokers and providers are bound to their requirements and related compensations through SLAs. An SLA specifies the details of the service to be provided in terms of metrics agreed upon by all parties, and penalties for meeting and violating the expectations, respectively. Side 30 af 87

31 5.5 CLOUD COMPUTING ÅBENHED Emner herunder føres ned i taksonomi struktur evaluering elementerne Hvilke probmstillinger findes, inddrag relevante kritiske artikler for at fremhæve problemer (IBM manifesto, ACM CTO Roundtables, Demystifying Cloud computing..): - vendor lockin (interoperabilitet er en del af løsning) - Sikkerhed (fysisk sikkerhed, datasikkerhed) - Interoperabilitet (Cloud services, Cloud to Cloud..) - Åbenhed og standarder Organisationer som arbejder for problemstillingerne: Open Cloud manifesto (whitepaper): - Principper for Cloud udvikling - Definition og taksenomi o service lag (pass, iaas..) o udrulningsmodeller (private, public, hybrid) - Model for standarder Open Cloud Consortium (OCC) - interoperabilitet mellem clouds - åbne standarder - open source - performance - arbejde med Clouds over store afstande European Union (EU) - Safe Harbor Principles, - The United States Department of Commerce and the European Commission have agreed on a set of data protection principles and frequently asked questions (the Safe Harbor Principles ) to enable U.S. companies to satisfy the requirement under European Union law that adequate protection is given to personal information transferred from the EU to the United States. Consistent with its commitment to protect personal privacy, the Companies adhere to the Safe Harbor Principles Side 31 af 87

32 Standarder relevante for at i møde gå problemstillinger: Open Cloud manifesto model for standarder relateret til taksonomi klassificerer standarder Standards typer: Standards Across Cloud Service Types Standards Within Cloud Service Types Standards Between the Cloud and the Enterprise Standards Within an Enterprise Levels of APIs Level 1 The Wire: Level 2 Language-Specific Toolkits: Level 3 Service-Specific Toolkits: Level 4 Service-Neutral Toolkits: Categories of APIs Category 1 Ordinary Programming: Category 2 Deployment: Category 3 Cloud Services: Category 4 Image and Infrastructure Management: Category 5 Internal Interfaces: - Data sikkerhed o WS* standarder : SAML etc. o Amazon er certificeret i SAS 70 Type II, ISO Interfaces Interoperbilitet o WS * standarder e.g. WSDL, SOAP, HTTP, HTML, XML, REST Side 32 af 87

33 5.6 CLOUD COMPUTING PRIS MODELLER Forbrugspris: Pay-as-you-go Fastpris: Måned pris (f.eks. Microsoft og Amazon) hvis man kender forbrugs størrelses orden Scenarie Eksempel med konfiguration, forbrug og pris, f.eks. baseret på Amazon eller Microsoft. Side 33 af 87

34 5.7 CLOUD COMPUTING OG SELF MANAGED ARKITEKTURER ANALYSE PRODUKT? (OPDATER) cloud computing (marked oriented architecture) and autonomic computing (self managed architecture) requirements Mapping af marked oriented cloud arkitektur med self managed arkitektur: Manager Elements (service consumer) Supporting elements: - negotiation (SLA, potilitikker) - discovery Elements (service provider) Managed Element Figur 5: Marked oriented arkitektur. Figur 6: Self managed arkitektur. Self managed arkitektur egenskaber CHOP Selv-configuration Automatiseret konfiguration af komponenter og system Self managed arkitektur krav Opførsel - Element - Relationer - Politikker (policies) Marked oriented cloud arktiektur egenskaber Support customer-driven service management based on customer profiles and requested Marked oriented cloud arktiektur krav Users/Brokers Side 34 af 87

35 som følger højniveau politikker. Resten af system justerer sig automatisk og problemfrit Self-healing Systemet detekterer automatisk, diagnosticerer og reparerer lokaliserede software og hardware problemer. Self-optimizing Komponenter og systemer søger kontinuerligt at forbedre deres ydelse og effektivitet Self-protecting Systemet forsvarer sig automatisk mod ondsindede angreb eller flere på følgende fejl. Det benytter tidlig advarsel og forhindrer fejl på system niveau. Interface - Element - Monitoring og test interfaces - Lifecycle interfaces - Politik interface - Negotiation og binding interfaces - Relationer (relationships) - Inteaction integrity System sammensætning - Interaktion - Discovery - Komposition - Støtte elementer service requirements Define computational risk management tactics to identify, assess, and manage risks involved in the execution of applications with regards to service requirements and customer needs Derive appropriate marketbased resource management strategies that encompass both customer-driven service management and computational risk management to sustain SLA-oriented resource allocation Incorporate autonomic resource management models that effectively self-manage changes in service requirements to satisfy both new service demands and existing service obligations Leverage VM technology to dynamically assign resource shares according to service requirements. SLA Resource Allocator - Service Request Examiner - Admission Control - Pricing - Accounting - VM Monitor - Dispatcher - Service Request Monitor VMs Physical Machines QoS Side 35 af 87

36 5.8 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 36 af 87

37 Stimulus Miljø Artefakt Svar Svar måleenhed En kondition der skal overvejes, når det ankommer til et system. Stimulus fremkommer indenfor bestemte konditioner. Dette kunne f.eks. være et system i en overbelastnings kondition. Et artefakt stimuleres. Dette kan være hele systemet eller dele af det. Svaret er den aktivitet der foretages på baggrund af ankomsten af stimulus. 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 Side 37 af 87

38 Svar måleenhed - genkende og ret bruger fejl - frembringe glemte password - 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 38 af 87

39 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 7 Foranalyse Eksperiment Evaluering Figur 7: 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 8. 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 8: 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 39 af 87

40 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 9. Kriterier Udvikle Case Evaluering Modenheds kvalificering Figur 9: 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 40 af 87

41 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 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 Kandidat 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) 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 Kandidat 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 Side 41 af 87

42 6.4.3 Scenarie 3: Tilvejebringelse af services Her skal to services kommunikere, så den ene f.eks. lytter på events fra den anden og er i stand til at fortolke informationen og sende svar tilbage. Kilde Stimulus Artefakt(er) Miljø Respons Måling Kandidat Lære at konfigurere fejlhåndteringsfunktionalitet. Fejlhåndteringsfunktionalitet Linux / Windows platform, med udviklingsmiljø konfigureret. Understøtte autonom håndtering af nedbrud og afvigelser. Opgaven skal kunne udføres på under 7 timer 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 Kandidat 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 Scenarie 5: Test Der arbejdes med at lære at realisere test af services. Kilde Stimulus Artefakt(er) Miljø Respons Måling Kandidat Lære at konfigurere test af services Udviklingsmiljø Linux / Windows platform, med udviklingsmiljø konfigureret. Test kode er kørende til test af service. Opgaven skal kunne udføres på under 7 timer. Side 42 af 87

43 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, 9] 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 (sprog, service : Paas, IaaS, SaaS, HaaS) 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 43 af 87

44 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 44 af 87

45 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å forskellige service tilgange: Platform as a service (PaaS) og Infrastructure as a service (IaaS). Id Navn Type License model Organisation K1 Azure [23] PaaS Kommerciel Microsoft Corporation K2 Elastic Compute Cloud (EC2) [24] IaaS Kommerciel Amazon K3 App Engine [25] PaaS Kommerciel Google K4 Network.com (Sun Grid) [26] PaaS Kommerciel Sun Microsystems Incorporated, Oracle K5 Aneka [27] 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 [28] IaaS Kommerciel GoGrid K7 Flexiscale [29] IaaS Kommerciel Flexiant K8 Mosso / Rackspace [30] IaaS Kommerciel Mosso er en underafdeling af Rackspace K9 Gigaspaces [31] PaaS Kommerciel Gigaspaces K10 RightScale [32] PaaS Kommerciel RightScale K11 Force.com [33] SaaS Kommerciel Salesforce K12 Eucalyptus [34] IaaS Open source Eucalyptus Systems K13 OpenNebula [35] IaaS Open source OpenNebula.org Kommercielle interesser varetages af C12G Labs K14 Nimbus [36] IaaS Open source Nimbus.org K15 Enomaly [37] IaaS Open source Enomaly K16 ElasticHosts [38] IaaS Kommerciel ElasticHosts Side 45 af 87

46 K17 Exaweb [39] IaaS Kommerciel Exaweb K18 Stormondemand [40] K19 Layered Technologies [41] IaaS Kommerciel Storm on demand er en underafdeling af Liquid Web Inc IaaS Kommerciel Layered Tech K20 Joyent [42] IaaS Kommerciel Joyent K21 Heroku [43] PaaS Kommerciel Heroku 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. Kandidaterne K4-K19 er fravalgt pga.: - Anvendelse af proprietær (K11), - Ikke fyldestgørende dokumentation eller værktøjsunderstøttelse (K6, K7, K16, K17, K18), - Ikke fyldestgørende opfyldelse af cloud computing og selfmanaged egenskaber (K6, K7, K8, K16, K17, K18, K19) - Udgået teknologi (K4) - En rammeværk teknologi, men ikke public cloud (K12, K13, K14, K15, K5, K9, K10) I det efterfølgende evalueres de 5 udvalgte teknologier. Side 46 af 87

47 7.1.3 Microsoft Azure Indledning Platform Anvendelsesdomæne Licensmodel Styringsmyndighed Vedligeholdelse Understøttede standarder Brugerunderstøttelse Værktøjsunderstøttelse Arkitektur Windows Azure platformen ses på Figur 10. Detalje beskrivelse findes i hhv. [2], [3] og [7]. På Figur 10 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 10: Windows Azure platformen [3]. Windows Azure platformen indeholder 3 komponenter, som yderligere er underopdelt: Side 47 af 87

48 1. Windows Azure Denne komponent udbyder et Windows miljø til afvikling af applikationer og lagring af disses data. På Figur 11 ses, at denne indeholder 5 delkomponenterne. Figur 11: Windows Azure komponent [2]. 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 12. Figur 12: Windows Azure applikation konfiguration og roller [2]. 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. Side 48 af 87

49 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 [4] eller udviklingmiljø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 nødvendigvis sendt til den samme instans af en given rolle. Applikationen må derfor ikke vedligeholde tilstand mellem forspørgelser, 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 [4] 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. Side 49 af 87

50 Storage Azure storage tilbyder flere lagringsmuligheder og typer, som det ses i Figur 13. Figur 13: Windows Azure storage elementer [2] 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 13. 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 lokalt fil system. Tables: Tillader at strukture 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) [8]. 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 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. Side 50 af 87

51 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 14 viser dette. Figur 14: Fabric Controller [2]. 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 [2]. Side 51 af 87

52 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 15. Figur 15: Content Delivery Network (CDN) [2]. 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 16. Figur 16: Connect [2]. 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 52 af 87

53 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 17. Figur 17: Azure SQL [3]. En applikation som er on-premises, i Windows Azure eller andre steder, kan tilgå database vha. en protokol kalder 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 53 af 87

54 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 18. Figur 18: Service Bus [3]. 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) [9] 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 54 af 87

55 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 19. Figur 19: Access Control [3]. 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. Evaluering Side 55 af 87

56 7.1.4 Amazon EC2 Indledning Platform Anvendelsesdomæne Licensmodel Styringsmyndighed Vedligeholdelse Understøttede standarder Brugerunderstøttelse Services beskrives med følgende elementer. - Guides, - Release notes, - Interface beskrivelse Web Services Specification Desription Language (WDSL) [28] - Community forum, - API documentation, - Artikler, - Turtorials, - Kode samples, - Support Værktøjsunderstøttelse Der findes AWS SDK til - Java(Eclipse), - PHP, - Ruby -.NET, - Python Der findes API tools til : - MAC Side 56 af 87

57 - Windows Arkitektur Amazon cloud computing [26, 27] teknologi er baseret på web services [29] og er samlet benævnt Amazon Web Services (AWS). Den grundliggende arkitektur for cloud computing er vist i Figur 20. Figur 20: AWS arkitektur[1]. Arkitekturen kan opdeles i 3 komponenter compute, storage og understøttende services. Compute Amazon Elastic Compute Cloud (EC2) [2] service udbyder et system virtual machine miljø til afvikling af applikationer. Der er understøttelse for Windows og Linux operativ systemer og forskellige 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 muligt at oprette, starte og stoppe VM instanser vha. Amzon Management Console[14] og fra web service interface fra en applikation. Mulige VM instanser ses i Tabel 6. Instans type CPU Hukommelse Instans lager Micro Small Medium Large Extra large Double extra large Quadruple Extra Large Tabel 6: VM konfigurationer [2]. Compute og storage services kan oprettes i forskellige geografiske lokationer, hvor de enkelte datacentrer er placeret. Lokationer findes i Side 57 af 87

58 - USA: Northern Virginia og Northern California - Europa: Ireland - Asian Pacific (APAC): Singapore Amazon Elastic MapReduce [3] 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 [4] service tillader automatisk at skalere VM instanser op eller ned baseret på politikker, som defineret af CloudWatch [16] metrikker f.eks. CPU belastning. Det er desuden muligt at modtage notifikationer vha. Amazon Simple Notification Service (SNS) [13], når en auto scaling aktivitet foretages. Amazon Elastic Load Balancing [5] 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 [7] 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 række, og tilknyttes attributes. Amazon Elastic Block Store (EBS )[8] 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 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) [9] 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. Side 58 af 87

59 Amazon Relational Database (RDS) [10] 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) [11] 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 [11] 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 [12] 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) [13] service tillader at notificere brugere om en specifik hændelse vha. eller HTTP/HTTPS, Amazon Web Services (AWS) Management Console [14] service tillader at styre AWS f.eks. stoppe og starte VM instanser eller oprette EBS volumes. Amazon Service Health Dashboard [15] service viser opdateringer drift tilstanden for de enkelte services fordelt på geografiske lokationer. Amazon CloudWatch [16] service leverer metrikker for de forskellige 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 [17] 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 Side 59 af 87

60 udføre arbejde. Det ønskede arbejde skal beskrives med en ønsket pris og resultat og eventuelle påkrævede kvalifikationer. Amazon Route 53 [18] service er en Domain Name System (DNS) service. Amazon Virtual Private Cloud (VPC) [19] 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) [20] 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) [21] service er en betalingsservice, som anvender Amazons betalingsinfrastruktur til at afregne med Amazon brugere for køb af produkter eller services. Amazon DevPay [22] 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 [23] service udbyder data om internet trafik herunder statistik for web sites og sites der henviser hertil. Alexa Top Sites [24] service tilbyder information om ranking af web sites og statistik. Amazon Identity and Access Management (IAM) [25] service tilbyder andre applikationer at håndtere brugere og deres rettigheder i AWS. Evaluering Side 60 af 87

61 7.1.5 Google App Engine Indledning Platform Anvendelsesdomæne 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 [33]. Resurse Enhed Enhed pris Outgoing Bandwidth gigabytes $0.12 Incoming Bandwidth gigabytes $0.10 CPU Time CPU hours $0.10 Stored Data gigabytes per month $0.15 Recipients ed recipients $ Tabel 7: App Engine pris model [22]. Styringsmyndighed Vedligeholdelse Understøttede standarder Brugerunderstøttelse Værktøjsunderstøttelse Side 61 af 87

62 Arkitektur Google App Engine er en cloud teknologi, som tillader web applikationer at blive afviklet på Googles infrastruktur [1, 2]. Applikationer bliver afviklet i en virtual machine af process virtual machine typen Figur 21. App Engine betår af 3 komponenter: Figur 21: App Engine arkitektur [3]. Runtime App Engine understøtter runtime miljøer i Java og Python. Java runtime kan afvikle Java Servlets og 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 Side 62 af 87

63 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, 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[7], 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. Indsæt referencer i nedenstående 1. Blobstore 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 En applikation kan anvende App Engine Google Accounts integration til at authenticate en bruger. API kan også anvendes til at håndtere applikationens brugerrettigheder Side 63 af 87

64 3. Channel Denne service opretter en forbindelse mellem applikationen og klienten af denne og tillader beskeder at blive sendt til klienten uden polling. 4. Images Denne service mulligør manipulation af billeder herunder størrelse og rotation af billeder i formaterne JPEG og PNG. 5. Mail Applikationer kan anvende denne service til at sende s. 6. Memcache 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 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). 8. Task Queues 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 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 Denne service anvendes af applikationen til at tilgå andre resurser på internettet herunder web service og data. 11. XMPP Extensible Messaging and Presence Protocol [31] (RFC 3921) er en service, som tillader en applikation at sende og modtage beskeder fra XMPP services, som f.eks. Google Talk. 12. DoS App Engine tilbyder en Denial of Service beskyttelse, som forhindrer IP adresser eller subnets i at foretage web forespørgsler til Side 64 af 87

65 Evaluering applikationen. Hermed forhindres applikationens kvoter også i at blive opbrugt Heroku Indledning Platform Anvendelsesdomæne Licensmodel Styringsmyndighed Vedligeholdelse Understøttede standarder Brugerunderstøttelse Værktøjsunderstøttelse Arkitektur Heroku er en PaaS cloud computing teknologi [1, 2] baseret på Amazon AWS infrastruktur. Herokus arkitektur er vist på Figur 22. Figur 22: Heroku arkitektur [2]. Arkitekturen består af 6 komponenter, som her er kategoriseret i compute, storage og andre services. Side 65 af 87

66 Compute Dyno Grid Applikationer afvikles i hvad der kaldes et Dyno grid [3, 4]. 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 [8] 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. Dyno En dyno er en proces som afvikler Ruby applikation kode [3, 4]. Strukturen af en Dyno ses på Figur 23. Figur 23: Heroku Dyno struktur [4]. 4 dyno svarer til en CPU core [4]. 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 [6]. 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. Side 66 af 87

67 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 [7] 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 [9] er baseret på open source teknologi fra PostgreSQL. Heroku muliggør automatisk og manuel backup snapshots af applikation database. Heroku tilbyder databaser baseret på Amazon RDS, MongoDB, CouchDB gennem Add-ons. Memory cache [2] 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 [2] 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 [5] 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 [2] 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 registrere de-registrere dynos. Evaluering Joyent Indledning Platform Anvendelsesdomæne Licensmodel Styringsmyndighed Vedligeholdelse Side 67 af 87

68 Understøttede standarder Brugerunderstøttelse Værktøjsunderstøttelse Arkitektur Joyent arkitektur består af 3 komponenter[1,6]. SmartMachine Joyent har defineret en SmartMachine [1,3,4, 6] 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 24. Figur 24: Joyent SmartMachine [5]. 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, hvor 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[17] 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. Side 68 af 87

69 - Integrated security: Operativ system kernel kan ikke manipuleres, da SmartOS isolerer hukommelse, CPU og netværk og blokerer netværks konfiguration og netværks sniffing. Hermed er applikationer isoleret fra hinanden. SmartDataCenter Joyent SmatDataCenter [1,5,6] er en abstraktion af data centret, hvori f.eks. SmartMachines afvikles, Figur 25. Figur 25: Joyent SmartDataCenter arkitektur [5]. 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) [] og Extensible Messaging and Presence Protocol (XMPP)[19]. 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. Side 69 af 87

70 Entensible, ressource-oriented architecture: Kunder kan tilføje eller fjerne resurser uden at dette har indvirkning på SmartDataCenter. SmartPlatform. Joyent arkitekturen udbyder udover IaaS tilgangen også en PaaS tilgang i SmartPlatform [1,2,6] i en sammensætning, som kan ses på Figur 26. Figur 26: Joyent SmartPlatform arkitektur [5]. SmartPlatform udbyder et udviklingsmiljø baseret på JavaScript server teknologi, som afvikles på SmartMachines. SmartPlatform skalerer automatisk applikationens resurse behov vha. SmartDataCenter efter. SmartPlatform er open sources og tillader dermed at blive afviklet i andre miljøer som ikke er baseret op Joyent teknologi. Figur 27 viser et eksempel på, hvorledes en web applikation kan skalere vha. Joyent SmartMachines. Figur 27: Joyent arkitektur skalering [7]. Side 70 af 87

71 Services Yderligere services kan tilkøbes eksisterende SmartMachines [9], listet nedenfor. 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å applikations klienten. Evaluering Evaluering (samlet evaluering) Konklusion Der vælges at fortsætte med teknologi kandidat Amazon AWS, da denne har god understøttelse af dokumentation, cloud computing og self managed arkitektur egenskaber 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 til at muliggør service discovery. Indenfor PaaS cloud teknologi kandidaterne Google App Engine og Heruko er forskellene ikke store. Indenfor storage har App Engine ikke understøttelse for en relational database. Heruko understøtter i dennes proces VM kun udviklingssproget Ruby (selvom der formentlig kommer Java understøttelse), hvori App Engine understøtter Java og Python. Heruko udfører ikke automatisk skalering ved f.eks. store belastninger dette har brugeren ansvaret for. Desuden har App Engine en større understøttelse af services i infrakture, hvorimod Heroku i stedet skal tilkøbe add-ons. Joyent Side 71 af 87

72 kan vha. SmartPlatform være PaaS, men kun med et basal udvikligsmiljø baseret på server JavaScript uden tilknyttede services. Indenfor IaaS er Amazon AWS og Microsoft Azure meget tæt. Azure understøtter ikke automatisk skalering baseret på politikker angivet af brugeren lige som Amazon AWS. Brugeren skal på forhånd kende belastningen. Både Azure og AWS har mange services, men især AWS har flere muligheder i APIer og er desuden implementeret vha. web service interface beskrivelser, hvilket giver en åben platform. En mulighed kunne være at anvende Azure og AWS i en intercloud konfiguration for at dække gaps de hver især har. Joyent mangler services og understøtter ikke automatisk skalering, dog kan en SmartMachine kortvarig burst, således en kortvarig belastning kan klares. Side 72 af 87

73 7.2 EKSPERIMENT I dette afsnit anvendes den valgte teknologi i et eksperiment for at afklare og evaluerer denne for brugbarheden vha. scenarier, som er beskrevet i afsnit 6.4. Brugbarheden af kandidaten evalueres ud fra useability 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 Der er valgt en case, som er baseret på en tidligere rapport [29] vedrørende kontrol af den kemiske proces i en kemisk fabrik [26, 27]. Uddrag af denne er angivet, som koncept på Figur 4 og kravs beskrivelse for det samlede system i Tabel 6. Denne case er valgt pga. de safety kritiske krav, som er stillet til systemet. Figur 4: Koncept system [26, 27]. Id Krav Kravs klasse Side 73 af 87

74 KR-1 KR-2 KR-3 KR-4 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å 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 hydrodynamiske 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 på Figur 4 i kontrolrummet i anlægget, således af beholderen vises med sensor og aktuator data og alarmere operatørerne i tilfælde af detekterede risici i systemet. Tabel 6: Overordnede arkitektur krav [26, 27]. Safety/business Business Funktionalitet / komponent Funktionalitet / komponent 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 5. Side 74 af 87

75 Figur 5: Safety kritisk deployment view [29], de markerede knuder realiseres i case. Casen afgrænses til komponenterne: - Kontrol - Monitor - Sensor par (temperatur og tryk) Dermed afgrænses casen til funktionelt at omhandle, at kontrol komponent periodisk indlæser sensor værdier, som kan følges vha. monitor komponent. 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 6 viser konceptuelt, hvorledes det autonome system vha. aspekterne self-healing og self-configuration kan realiseres vha. kandidaten udvalgt. Side 75 af 87

76 Figur 6: Afgrænset autonome system koncept af CP09. Kontrol komponenten har i service beskrivelsen angivet vha. en politik, at værdierne fra sensor services ikke må afvige med fastsatte grænseværdier, hvilket kan indikere sensor service fejl, ellers kan den kemiske proces ikke styres korrekt. I tilfælde af dette ikke kan overholdes skal Kontrol komponenten finde en tilsvarende service og etablere forbindelse. Dette er på Figur 6 vist med operationerne: 1. Politik brudt (sensor uden for grænseværdi) 2. En ny service findes og forbindelse etableres Disse aspekter af self management skal den valgte kandidat evalueres ud fra Design Design module viewpoint for services, som skal realiseres i de efterfølgende usability scenarier er vist på Figur 7. Deployment view er vist i case beskrivelsen og connector og component view er vist i tidligere opgave [29]. Side 76 af 87