Evaluering af Udbud og Modenhed af Cloud Computing Software Teknologier Præsentation af hovedopgave og resultater Vejleder: Henrik Bærbak Christensen Af:

Præsentationer af emnet: "Evaluering af Udbud og Modenhed af Cloud Computing Software Teknologier Præsentation af hovedopgave og resultater Vejleder: Henrik Bærbak Christensen Af:"— Præsentationens transcript:

1 Evaluering af Udbud og Modenhed af Cloud Computing Software Teknologier Præsentation af hovedopgave og resultater Vejleder: Henrik Bærbak Christensen Af: Thomas Mollerup Lanng 20070583 {u070583@cs.au.dk, thomas.lanng@gmail.com} Dato: 04.02.2011

2 Disposition Præsentation af hoved ideerne i hovedopgave: – Motivation – Problemstilling – Hovedkonklusioner Detaljeret redegørelse for eksperimentet omkring udvikling af services, usability scenarie 2, afsnit 7.3.2.

3 Motivation og problemstilling

4 Motivation Cloud computing : Aktuelt emne og spændende emne, hvordan kan dette emne sættes i en problem kontekst Vs. Definition af Cloud computing [Buyya et al.]: En cloud er en parallel og distribueret type system bestående af en samling forbundne og virtualiserede computere, som allokeres dynamisk og præsenteres som en computer ressource baseret på service level agreements (SLA) etableret gennem forhandling mellem service udbyder og service brugere Definition af Autonomic computing [Kephart et al.]: Store computer systemer, der styrer sig selv i forhold til højniveau målsætninger fra mennesker. De lever deres eget liv og fungerer autonomt i deres miljø.

5 Motivation [Buyya] definerer en markeds baseret Cloud arkitektur med følgende krav til kommercielle produkter. Krav idBeskrivelse K.1 Support customer-driven service management based on customer profiles and requested service requirements K.2 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 K.3 Derive appropriate market-based resource management strategies that encompass both customer-driven service management and computational risk management to sustain SLA-oriented resource allocation K.4 Incorporate autonomic resource management models that effectively self-manage changes in service requirements to satisfy both new service demands and existing service obligations K.5Leverage VM technology to dynamically assign resource shares according to service requirements. QoSQoS 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.

6 Motivation [White et. al] definerer en self managed arkitektur til opfyldelse af autonomic computing aspekter [White et. al] definerer krav et autonomt element som indgår i den self managed arkitektur. Aspekt Beskrivelse Self- configuration Automatiseret konfiguration af komponenter og system som følger højniveau politikker. Resten af system justerer sig automatisk og problemfrit. Self-healingSystemet detekterer automatisk, diagnosticerer og reparerer lokaliserede software og hardware problemer. Self-optimizingKomponenter og systemer søger kontinuerligt at forbedre deres ydelse og effektivitet. Self-protectingSystemet forsvarer sig automatisk mod ondsindede angreb eller flere på følgende fejl. Det benytter tidlig advarsel og forhindrer fejl på system niveau.

7 . HovedkategoriUnderkategoriKrav IdKrav beskrivelse OpførselElementKO.1Skal 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.2Skal 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 ) RelationerKO.3Etablere og vedligeholde relationer med andre autonome elementer herunder hvilke services udbydes til og services som benyttes KO.4Service skal beskrives korrekt og være tilgængelig og forståelig for andre autonome elementer KO.5Skal forstå og opfylde aftale krav KO.6Skal kunne forhandle for at etablere aftaler (relationer) KO.7Skal 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 Politikker (policies)KO.82 typer forpligtigelse(obligations): - opfylde aftaler(agreements) og - modtage og opfylde politikker(policies) KO.9Skal forkaste service forespørgsler som bryder politikker eller aftaler KO.10Skal nægte eller give andre forslag til foreslåede relationer eller politikker som vil bryde eksisterende relationer eller politikker KO.11Administrative relationer håndteres lige som andre relationer KO.12Direktiver 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 KO.13Konfliktende forespørgsler fra administrative elementer skal løses af det modtagne element KO.14Skal kunne oversætte højniveau, globale direktiver til specifikke aktiviteter vha. politikker KO.15En politik er en repræsentation i en standard ekstern form for ønskede opførsel eller begrænsninger på opførsel KO.16Der tillades mindst 3 niveauer af relaterede politikker: - Action politikker er den laveste politik specifikation, som typisk har en if-then kontrol struktur f.eks. If(ResponseTime > 2 sec) Then (CPU+5%) - Et autonomt element der benytter action politikker skal måle kvantiteterne beskrevet i betingelsen(If) og udføre action (Then), når betingelsen er opfyldt - Mål politikker (goal policies) er det mellemste niveau af politikker, som beskriver betingelser som skal opfyldes, men uden at beskrive hvordan, dette kunne f.eks. være respons tid må ikke overstige 2 sek. - Utility function politikker er det højeste niveau af politikker, som at specificere de relative ønskede alternative tilstande, hvilket opnås ved at tildele en numerisk værdi eller en partiel eller fuldstændig beskrivelse af rækkefølge for mulige tilstande KO.17Et autonomt element, der benytter action politikker, skal måle kvantiteterne beskrevet i betingelsen(If) og udføre action (Then), når betingelsen er opfyldt KO.18Et element, der benytter Utility function politikker, skal have tilstrækkelig modellering og optimeringsegenskaber for at oversætte mål til actions InterfaceElementKI.1Udover 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 Monitoring og test interfaces KI.2Dette gør det muligt for at et element at blive monitoreret af et andet element med de nødvendige rettigheder KI.3Kan anvendes til at styre mængden af logning og trace data, som et element indsamler og få tilgang til dette data KI.4Kan anvendes til at instruere et element til at udføre en self-test og tilgå resultater Lifecycle interfacesKI.5Muliggø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.6Muliggør ændring af lifecycle tilstand for et element f.eks. nedlukning Politik interfaceKI.7Muliggør for administrative elementer at sende nye politikker til et element og politikker som anvendes at elementet Negotiation og binding interfaces KI.8Tillader et element at forespørge en service fra et andet element eller at blive forespurgt at levere en service KI.9I 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 KI.10I 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 Relationer (relationships) KI.11Opstår når et element har tilladt at levere en service til et andet element typisk ved forhandling mellem elementerne KI.12En forhandling kan fejle som følge af manglende rettigheder eller elementet ikke har tilstrækkelige ressourcer KI.13Relationer er måden hvorpå elementer sammensættes til at danne et autonomt system KI.14Relationer dannes typisk runtime (modsat fastholdt ved udrulning) og kan ændres på et givent tidspunkt KI.15Relationer dannes af elementerne selv og ikke af administratorer Inteaction integrityKI.16Et 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.17Et elements interne kommunikation må ikke blive tilgængelig udenfor elementet System sammensætning InteraktionKS.1For 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. DiscoveryKS.2Autonome elementer skal kunne finde/søge andre elementer KS.3Autonome elementer skal kunne identificere andre elementer for kommunikation KompositionKS.4Autonome elementer skal via andre elementer kunne opnå end-to-end service level mål Støtte elementerKS.5For at opnå dette anvendes et antal af infrastruktur elementer: Registry: - Tilbyder mekanismer således elementer kan finde andre elementer og forbinde sig med hinanden - Tilbyder mekanismer således elementer kan publicere services Sentinel: - Tilbyder services til monitorering for andre elementer Aggregator: - Kombinere 2 eller flere elementer, således at en forbedret services kan tilbydes f.eks. højere pålidelighed eller performance end elementer hver for sig er i stand til Broker: - Faciliteter interaktion f.eks. ifm. at støtte et element med at udføre opgaver som kræver komplekse relationer - 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

8 Motivation Cloud computing og Autonomic computing forekommer at have lignende egenskaber indenfor ressource management baseret på politikker Definere problemformulering, hvor cloud computing teknologier undersøges for understøttelse af autonomic computing.

9 Problemstilling I denne rapport foretages en evaluering af udbud og modenhed af cloud computing teknologier, der understøtter autonom computing teorien, som defineret af [Kephart et al.] 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?

10 Problemstilling Modenheden af de udvalgte cloud computing teknologier vurderes ud fra en evalueringstaksonomi med følgende kriterier: – Hvor godt understøttes autonomic computing teorien? – Hvor svært er det at anvende (defineret vha. usability kvalitetsattribut scenarier)? – Hvor god er dokumentationen? – Hvordan vedligeholdes teknologien? – Hvilken værktøjs understøttelse findes? – Hvilke standarder understøttes?

11 Metode Problemformuleringen behandles i en faseopdelt metode, som tillader planlægning af opgave i tids opdelinger. Aktiviteter i faserne, som er styret af kriterier

12 Metode Taksonomi og evaluerings kriterier

13 Hovedkonklusioner

14 Foranalyse – Udbud af teknologi kandidater Eksperiment – Usability scenarier Samlet konklusion – Problemstilling

15 Hoved konklusioner - Foranalyse Stor brutto kandidatliste for cloud computing teknologier - projektet fortsatte ift. Beslutning ’gate’ 21 kandidater fundet – Fravalgte kandidater klassificeret i: Udgået teknologi Ikke baseret på public cloud model Anvendelse af proprietær teknologi som ikke tillader åbenudvikling på platform Mangel på brugerdokumentation og værktøjsunderstøttelse Mangel på understøttelse af cloud computing og self managed arkitektur egenskaber 5 kandidater udvalgt – Microsoft Azure – Heroku – Amazon Web Services (AWS), EC2 – Joyent – Google App Engine

16 Hoved konklusioner - foranalyse Kandidater Kriterier Evaluering Microsoft AzurePlatformAzure er PaaS med mulighed for IaaS for Windows server virtuel maskine. Asure understøtter.Net teknologi og har mulighed for konfiguration af andre runtime miljøet herunder Java. Anvendelsesdomæne LicensmodelAzure understøtter: forbrugsmodel og abonnent model, hvor der betales et fast beløb for en periode, herefter time prisen reduceres for ressourcen. Styringsmyndighed Understøttende standarderAzure understøtter.NET teknologi, web services teknologi REST for infrastruktur services og egne teknologier til f.eks. databaser vha. TDS. VedligeholdelseUdfører vedligeholdelse af udviklingssoftware, service interfaces og instans software med daglig, månedlig og kvartal frigivelsesplaner. BrugerunderstøttelseLeverer dokumentation af service interfaces og udviklingssoftware samt guides. Desuden gives mulighed for bruger interaktion i form af fora og andre kanaler VærktøjsunderstøttelseLeverer software udviklingsværktøj (SDK) til applikationsudvikling. Leverer udover.NET også til Ruby, Java og PHP. Understøtter Eclipse IDE integration. Arkitektur KvalitetsattributterUdføres på udvalgte kandidat i eksperiment

17 Hoved konklusioner - foranalyse Kandidater Kriterier Evaluering Heroku PlatformHeroku er PaaS baseret på Ruby teknologi. Anvendelsesdomæne LicensmodelUnderstøtter en forbrugsmodel. Styringsmyndighed Understøttende standarderHeroku anvender Ruby til runtime miljø og applikationsudvikling. Derudover anvendes REST til applikations management service. VedligeholdelseUdfører vedligeholdelse af udviklingssoftware, service interfaces og instans software med daglig, månedlig og kvartal frigivelsesplaner. BrugerunderstøttelseLeverer dokumentation af service interfaces og udviklingssoftware samt guides. Desuden gives mulighed for bruger interaktion i form af fora og andre kanaler VærktøjsunderstøttelseLeverer software udviklingsværktøj (SDK) til applikationsudvikling Arkitektur KvalitetsattributterUdføres på udvalgte kandidat i eksperiment.

18 Hoved konklusioner - foranalyse Kandidater Kriterier Amazon Web Services (AWS), EC2 PlatformEC2 er IaaS og understøtter virtuelle maskiner baseret på forskellige operativ systemer med mulighed for konfiguration af forskellige runtime miljøer og applikationer. Anvendelsesdomæne LicensmodelEC2 understøtter: forbrugsmodel (on demand), udbudsmodel (spot instances), hvor der bydes på den billigste ressource og abonnent model (reserved instans), hvor der betales et fast beløb for en periode, herefter time prisen reduceres for ressourcen. Styringsmyndighed Understøttende standarderEC2 understøtter web services teknologier REST og SOAP til beskrivelse af infrastruktur services. VedligeholdelseUdfører vedligeholdelse af udviklingssoftware, service interfaces og instans software med daglig, månedlig og kvartal frigivelsesplaner. BrugerunderstøttelseLeverer dokumentation af service interfaces og udviklingssoftware samt guides. Desuden gives mulighed for bruger interaktion i form af fora og andre kanaler VærktøjsunderstøttelseLeverer software udviklingsværktøj (SDK) til applikationsudvikling. Leverer SDK til Java, PHP, Ruby,.NET og Python. Understøtter Eclipse IDE og Visual Studio integration. Arkitektur KvalitetsattributterUdføres på udvalgte kandidat i eksperiment.

19 Hoved konklusioner - foranalyse Kandidater KriterierEvaluering Joyent PlatformJoyent er IaaS og understøtter forskellige operativ systemer med mulighed for konfiguration af forskellige runtime miljøer hovedsagelig baseret på GNU applikationer. Joyent benytter eget operativ system, SmartOS, som også anvendes til virtualisering af andre operativ system herunder Windows og Linux. Anvendelsesdomæne LicensmodelUnderstøtter en forbrugsmodel. Styringsmyndighed Understøttende standarderJoyent tilbyder ikke udviklingssoftware og har ingen infrastruktur services, som instanser kan tilgå. VedligeholdelseIngen software til vedligeholdelse BrugerunderstøttelseLeverer ikke udviklingssoftware eller yderligere services VærktøjsunderstøttelseLeverer ikke udviklingssoftware eller yderligere services Arkitektur KvalitetsattributterUdføres på udvalgte kandidat i eksperiment.

20 Hoved konklusioner - foranalyse Kandidater KriterierEvaluering Google App Engine PlatformApp Engine er PaaS baseret på Java og Python teknologi. Anvendelsesdomæne LicensmodelUnderstøtter en forbrugsmodel. Tilbyder kvoter for forbrug, således at det er muligt at sætte en begrænsning på forbrug af ressourcen. Styringsmyndighed Understøttende standarderApp Engine anvender Java og Python til runtime miljø og applikationsudvikling. VedligeholdelseUdfører vedligeholdelse af udviklingssoftware, service interfaces og instans software med daglig, månedlig og kvartal frigivelsesplaner. BrugerunderstøttelseLeverer dokumentation af service interfaces og udviklingssoftware samt guides. Desuden gives mulighed for bruger interaktion i form af fora og andre kanaler VærktøjsunderstøttelseLeverer software udviklingsværktøj (SDK) til applikationsudvikling. understøtter Eclipse IDE integration. Arkitektur KvalitetsattributterUdføres på udvalgte kandidat i eksperiment.

21 Hoved konklusioner - foranalyse Foranalyse – Microsoft Azure

22 Hoved konklusioner - foranalyse Foranalyse – Microsoft Azure

23 Hoved konklusioner - foranalyse Foranalyse – Amazon EC2 (Amazon Web Services – AWS)

24 Hoved konklusioner - foranalyse Foranalyse – Google App Engine

25 Hoved konklusioner - foranalyse Foranalyse – Heroku

26 Hoved konklusioner - foranalyse Foranalyse – Joyent

27 Hoved konklusioner - eksperiment Mapning af AWS til autonomic self managed arkitektur elementer – Manager – Managed element

28 Eksperiment - 1 Detaljeret redegørelse for eksperimentet omkring udvikling af services, usability scenarie 2, afsnit 7.3.2. Arkitektur design problemer/kvalitetskrav - case: skalere ved overbelastning - availability taktik: EC2 detektere instanser i forkert tilstand, Auto scaling opstarter ny instans - Auto scaling starter ny instans ved cpu overbelastning Problemet og løsningen… – Patterns / Styles baseret på skema Kontekst: design kontekst, som hvori design problem opstår Problem: gentaget problem, som opstår i konteksten Løsning: konfiguration som skal balancere problemerne – Struktur med komponenter og relationer – Run-time opførsel Konsekvenser – Single point of failure – Marshalling – kvaliteter: Data integrability: clients are independent Modifiability (decouple sender and receiver) Availability, Scalability (indsætte flere komponenter) location transparency modifiability wrt. re-configurations of network marshalling/unmarshalling – Architectural Tactics A design decision that influences the control of a quality attribute response Surgical means for getting a quality E.g., Heartbeat to control availability Cloud Computing Kvalitetsattributter – Uafhængighed – Høj koherens (samhørighed) – Skalering Arkitektur styles og kvalitetsattributter

29 Eksperiment - 1 Detaljeret redegørelse for eksperimentet omkring udvikling af services, usability scenarie 2, afsnit 7.3.2. Arkitektur styles og kvalitetsattributter – Giver kvalitet(er) – Patterns / Styles baseret på skema Kontekst: design kontekst, som hvori design problem opstår Problem: gentaget problem, som opstår i konteksten Løsning: konfiguration som skal balancere problemerne – Struktur med komponenter og relationer – Run-time opførsel konsekvenser Definition [196]: en arkitektur style er en beskrivelse af komponent typer og et pattern for deres runtime kontrol og data overførsel. En arkitektur style definerer desuden begrænsninger for komponent typer og interaktions pattern. Arkitektur styles beskriver også arkitekturer med specifikke kvaliteter, således at kvalitetskrav til en arkitektur opfyldes, hvis en given arkitektur style anvendes. En arkitektur style eller pattern beskrives ligesom med design patterns med et navn, en kontekst, et gentaget problem som optræder i konteksten og en løsning.

30 Eksperiment - 2 Arkitektur styles – (Klient – Server) RMI – (Web services arkitektur - Restfull) Adressering af unikke ressourcer Selvbeskrivende service interfaces AWS – Broker (observer-listener pattern) – Blacboard (queue)

31 Eksperiment - bb Arkitektur styles – Blacboard (queue) – Data struktur Message type: angiver komponent navnet på afsenderen af beskeden Message: angiver en besked fra afsenderen f.eks. at den er opstartet Value: angiver værdier fra sensorer MachineName: netværksnavnet for den virtuelle maskine MachineAddress: netværksadressen eller IP adressen for den virtuelle maskine Timestamp: angiver tidspunktet beskeden var afsendt Message { "Type" : "", "Message" : "", "Value" : "", "MachineName" : "", "MachineAddress" : "”, "Timestamp" : "" }

32 Eksperiment - 3..

33 Eksperiment - 4

34 Konklusion

35 Referencer Software Architecture in Practice 2nd Ed, Bass, Clements, and Kazman, Addison-Wesley, 2003 Pattern-oriented software architecture – A system of patterns, Volume 1, Buschmann et al., John Wiley and Sons Ltd., 2001 Hovedopgave, Master i Informationsteknologi linien i Softwarekonstruktion, Evaluering af Udbud og Modenhed af Cloud Computing Software Teknologier, Thomas Mollerup Lanng, 2011, https://master-evu-au- 2010.googlecode.com/svn/trunk/docs/R04.pdf