Præsentation er lastning. Vent venligst

Præsentation er lastning. Vent venligst

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

Lignende præsentationer


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æneEn uafhængig software leverandør (independent software vendor - ISV) kan udvikle applikationer målrettet forretningsbrugere. Software as a Service (SaaS) En ISV kan målrette en SaaS applikation til forbruger grupper Organisationer kan anvende Microsoft Azure til udvikling af applikationer til ansatte LicensmodelAzure understøtter: forbrugsmodel og abonnent model, hvor der betales et fast beløb for en periode, herefter time prisen reduceres for ressourcen. StyringsmyndighedMicrosoft corporation. 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. ArkitekturAzure opfylder delvis autonomic computing krav. I forhold krav Politikker KO.8-18 er det ikke muligt vha. politikker at bestemme, hvordan systemet skal opfører sig i givne situationer f.eks. under CPU belastning. I forhold krav Interfaces krav KI.1-17 er der ikke mulighed for at forespørge tilstanden eller lifecycle model af en given service. KvalitetsattributterUdføres på udvalgte kandidat i eksperiment

17 Hoved konklusioner - Foranalyse Kandidater Kriterier Evaluering Heroku PlatformHeroku er PaaS baseret på Ruby teknologi. AnvendelsesdomæneMålretter platformen til udvikling af web applikationer LicensmodelUnderstøtter en forbrugsmodel. StyringsmyndighedHeroku incorporated fra den 31. januar 2011 en underafdeling af Salesforce.com incorporated. 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 ArkitekturHeroku opfylder delvis autonomic computing krav. I forhold til krav Element KO.1, KO.2 og Relationer KO. 3-7 og System KS.1-5 gives der ikke mulighed for service discovery for understøttelse af konfiguration af service sammensætning. Desuden findes der ikke mekanismer eller services for selvbeskyttelse i forhold til krav Element KO.1, KO.2. I forhold krav Politikker KO.8-18 er det ikke muligt vha. politikker at bestemme, hvordan systemet skal opfører sig i givne situationer f.eks. under CPU belastning. I forhold krav Interfaces krav KI.1-17 er der ikke mulighed for at forespørge tilstanden eller lifecycle model af en given service. 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æneEn infrastruktur web services platform, som kan tilbydes organisationer af forskellige størrelser. Computer, lagring og andre services kan købes efter forretningsbehov. Der er mulighed for at vælge udviklingsplatform og programmering model efter det specifikke behov. Forskellige forretningsområder nævnes, som målgrupper for den fleksible udvidelse af ressourcer, herunder e- handel, som ikke kan forudsige web trafik, farmaceutiske organisationer med behov for simulationer i stor skala og medie organisationer som kan levere video, musik og andet 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. StyringsmyndighedAmazon Web Services Limited Liability Company (LLC) ejet af Amazon.com incorporated. 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. ArkitekturEC2 opfylder delvis autonomic computing krav. I forhold til krav Relationer KO.3-7 og System KS.1-5 gives der ikke mulighed for service discovery for understøttelse af konfiguration af service sammensætning. 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æneMiljøer, hvor applikationer hurtigt skal skalerer vertikalt eller horisontalt for at behandle uventede trafik krav. LicensmodelUnderstøtter en forbrugsmodel. StyringsmyndighedJoyent incorporated 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 ArkitekturJoyent opfylder delvis autonomic computing krav. I forhold til krav Element KO.1, KO.2 og Relationer KO. 3-7 og System KS.1-5 gives der ikke mulighed for service discovery for understøttelse af konfiguration af service sammensætning. I forhold krav Politikker KO.8-18 er det ikke muligt vha. politikker at bestemme, hvordan systemet skal opfører sig i givne situationer f.eks. under CPU belastning. I forhold krav Interfaces krav KI.1-17 er der ikke mulighed for at forespørge tilstanden eller lifecycle model af en given service. 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æneBeskriver ikke specifikke anvendelses domæner, men App Engine afvikler applikationer efter f.eks. Java Servlet og JavaServer Pages og er derfor målrettet web applikationer. LicensmodelUnderstøtter en forbrugsmodel. Tilbyder kvoter for forbrug, således at det er muligt at sætte en begrænsning på forbrug af ressourcen. StyringsmyndighedGoogle incorporated. 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. ArkitekturApp Engine opfylder delvis autonomic computing krav. I forhold til krav Element KO.1, KO.2 og Relationer KO. 3-7 og System KS.1-5 gives der ikke mulighed for service discovery for understøttelse af konfiguration af service sammensætning. I forhold krav Politikker KO.8-18 er det ikke muligt vha. politikker at bestemme, hvordan systemet skal opfører sig i givne situationer f.eks. under CPU belastning. I forhold krav Interfaces krav KI.1-17 er der ikke mulighed for at forespørge tilstanden eller lifecycle model af en given service. KvalitetsattributterUdføres på udvalgte kandidat i eksperiment.

21 Hoved konklusioner - Foranalyse Pris sammenligning Pris pr. time i dollars for CPU kerner for teknologierne. Heroku er omregnet til 4 applikations instanser svarende til en CPU kerne. EC2 har en ikke-lineær funktion for pris og ressource element. Dette skyldes, at Amazon tilbyder instans konfiguration med forskellige hukommelse og lager konfigurationer for given antal CPU kerner.

22 Hoved konklusioner - Foranalyse Pris sammenligning Pris pr. time i dollars for instans lagerplads i MB for teknologierne.

23 Hoved konklusioner - Foranalyse Pris sammenligning Pris pr. time i dollars for instans hukommelse i MB for teknologierne.

24 Hoved konklusioner - Foranalyse Pris sammenligning fordeling af placeringer TeknologiCPUHukommelseLager Azure322 EC2111 App Engine2ikke oplyst Heroku4ikke oplyst Joyent555

25 Hoved konklusioner - Foranalyse Der vælges at fortsætte med teknologi kandidat Amazon AWS EC2. Denne har god understøttelse af dokumentation, blandt de bedste for understøttelse af cloud computing og self managed arkitektur krav samt værktøjsunderstøttelse for debug, service interface og udrulning af services. Desuden har den en meget fyldestgørende understøttelse af forskellige web services uden dog et service registry, som muliggør service discovery og service sammensætning. Forbrugsprisen er den laveste af teknologierne, hvilket reducerer omkostninger i udviklingsprocessen. Service findes i datacenter i Europa, således forbindelsen ikke bliver etableres til f.eks. USA med mulighed for forsinkelser på data trafik. Der findes SDK til Java, hvilket giver forfatteren mulighed for at anvende kendskab og erfaring til udvikling af case. EC2 er IaaS, hvilken i forhold til PaaS, betyder, at runtime miljø skal installeres og konfigureres i de virtuelle instanser.

26 Eksperiment

27 Usability scenarier driver eksperimentet og realiserer CP09 casen Casen afgrænser CP09 systemet til komponenterne: – Kontrol – Monitor – Sensor par (temperatur og tryk) – Aktuator Kontrol komponent indlæser periodisk sensor værdier Monitor komponent visualisere sensor værdier Ved temperatur værdier over 30 grader celsius sendes en besked til varmelegeme aktuator om at reducere temperaturen. Tryk behandles ikke i casen ud over en visuel repræsentation vha. Monitor komponenten. Systemet har angivet vha. en politik, at hvis en komponent i systemet belastes med mere end 80 % af CPU kapaciteten, så skal der startes en ny virtuel maskine instans for den givne komponent type. Disse aspekter af self management skal den valgte kandidat evalueres ud fra. Aspekterne self-healing og self-configuration

28 Eksperiment Usability scenarie 2 – Udvikling af første services – Systemets komponenter udvikles givet casens afgrænsning Proces steps – Valg af arkitektur style – Beskrivelse af komponenter – Implementering – Test KildeForfatteren af rapport og udvikleren af case StimulusLære at lave services, der kommunikerer med hinanden. Artefakt(er)Kodegenerering, command line interface, associeringsfunktionalitet MiljøLinux / Windows platform, med udviklingsmiljø konfigureret. ResponsUnderstøttelse for udvikling af interservice kommunikation. MålingOpgaven skal udføres på under 7 timer

29 Eksperiment Valg af arkitektur style / pattern [Buschmann] – Definition [Bass]: 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 Valg af arkitektur style / pattern [Buschmann] – Problem Placerings transparens: Control skal kunne tilgå sensor værdier uden at kende netværks adresse Komponenter skal være uafhængige af hinanden og må derfor ikke kommunikere direkte med hinanden. Modifiability: det skal være muligt at indsætte flere sensorer eller andre komponenter uden at foretage konfiguration – Løsning Kandidater Blackboard – Funktionalitet for denne findes i platformen i form a Simple Queue Service Broker – Der findes ikke Broker / Service registry funktionalitet i AWS platformen, derfor skal denne udvikles eller installeres i platformen – Konsekvenser Bloakboard vælges, hvilket betyder, at der skal ændres på hvorledes komponenterne kommunikerer I modsætning til Broker er der ikke funktionalitet til marshalling / unmarshalling af beskeder Kontrol kan ikke kommunikere med sensorer, som om de er lokale objekter Begge kandidater er single point of failure (Broker/Control) muligheder med mindre availability taktikker anvendes Der skal udvikles en Queue test stub i stedet for en f.eks. et Java RMI registry Manlende mulighed for anvendelse af observer pattern for sensorer, som Kontrol og Monitor kan abonnere på Definition [Bass]: en arkitektur style er en beskrivelse af komponent typer og et pattern for deres runtime kontrol og data overførsel.

31 Eksperiment Beskrivelse af komponenter – Ændring af ansvar KomponentAnsvar MonitorDer oprettes en Monitor kø, hvortil Control knude kan sende sensorværdier læst fra sensor kø og SNS service kan sende alarmer fra CloudWatch. Hertil sendes også hændelser foretaget af Actuator f.eks. ved åbning af ventil. Desuden sendes deployment beskeder, når komponenter starter i instanser. Monitor knude skal slette beskeder læst fra denne kø. ControlDer oprettes en Control kø, hvortil Sensor par knude skriver sensorværdier for temperatur og tryk. Control knude skal slette beskeder læst fra denne kø. Sender deployment besked til Monitor, når komponenter startet instansen ActuatorDer oprettes en Actuator kø, hvortil Control sender kommandoer for styring af temperatur, tryk og produktion. Actuator knude skal slette beskeder læst fra denne kø. Sender deployment besked til Monitor, når komponenter startet instansen SensorSensor par sender beskeder til Control indeholdende aflæste beskeder. Sender deployment besked til Monitor, når komponenter startet instansen

32 Eksperiment Beskrivelse af komponenter – Besked data struktur, JSON 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" : "" }

33 Eksperiment Component & Connector view

34 Eksperiment Component & Connector view

35 Eksperiment Module view

36 Eksperiment Module view – Beskrivelse af pakker PakkeBeskrivelse cp09.monitorguiDenne pakke indeholder realiseringen af GUI delen for Monitor og Controller og View delen af MVC pattern cp09.monitorDenne pakke indeholder realiseringen af Monitor model delen af MVC pattern. cp09.sensorDenne pakker indeholder realiseringen af temperatur og tryk sensorer med simulerede sensor værdier. cp09.actuatorDenne pakke indeholder realiseringen af Actuator. cp09.controlDenne pakke indeholder realiseringen af Control. cp09.loggingDenne pakke indeholder realiseringen af logging funktionalitet til konsol og fil log. cp09.instanceDenne pakke indeholder realiseringen af funktionalitet til kommunikation med EC2 service og Auto Scaling service. cp09.queueDenne pakke indeholder realiseringen af funktionalitet til kommunikation med Simple Queue service. cp09.messageDenne pakke indeholder realiseringen af CP09 JSON baseret beskeds system.

37 Eksperiment Module view

38 Eksperiment Module view

39 Eksperiment Deployment view

40 Eksperiment System test – lokal deployment

41 Eksperiment System test – lokal deployment

42 Eksperiment

43

44 Implementering Test

45 Eksperiment Implementering

46 Konklusion - Eksperiment Scenarierne målt på de definerede tids metrikker fejlede. Dette skyldes problemer i platformen, som skulle undersøges hvilket resulterede i, at aktiviteterne i scenarierne blev afbrudt. Problemerne blev identificeret til at være klassificeret til at være en del af leveret udviklingssoftware og selve platformen. Det første problem relateret til platformen og udviklingssoftware var konfiguration af adgangssystemet for de enkelte køer i platformen kø service. Dette skyldes en fortolknings fejl af den definerede adgangspolitik, som ikke understøttede deklareringen af en sammenlignings statement. Den efterfølgende fundne fejl var af en mere alvorlig karakter. Tidligt i det første scenarie rapporterede EC2 servicen fejl, når der blev for søgt at starte EC2 instanser i USA og APAC regionen. Da problemet blev undersøgt blev der fundet lignende problemer på AWS status site. Selvom problemet blev rapporteret til Amazon med en detaljeret beskrivelse, blev status overblikket ikke opdateret for tidspunktet, hvor problemet blev observeret. Da der blev undersøgt nærmere på fora om der fandtes lignende problemer, blev en løsning beskrevet, hvor en Auto Scaling group defineres til at starte EC2 instanser i flere regioners availability zones for dermed at sikre tilgængeligheden af ressourcerne. Denne taktik blev også anvendt under testen, em begge availability zones defineret for Auto Scaling gruppen fejlede. Det andet platform service orienteret problem, blev fundet i det sidste scenarie, da systemet var endelig designet og realiseret. Det lykkedes ikke, at aktiveret en CloudWatch alarm for metrikken CPU utilization, således skalering af flere EC2 instanser kunne demonstreres, når system bliver belastet. Modsat kunne CloudWatch alarmen for lav CPU belastning aktiveres og dette blev registreret i CP09 systemet Monitor GUI hændelse log. Subjektiv giver det umiddelbart indtryk af en umoden platform. Men der er også mange teknologi muligheder i platformen. For eksempel understøttes virtuelle maskiner med mange forskellige konfigurationer. Komponenter eksisterer i platformen for at varetage elementer i den self managed autonomic computing arkitektur. Manager delen er delt mellem CloudWatch, Auto Scaling og EC2 service. CloudWatch har til ansvar at monitorere det managed element, EC2 service skal administrerer ressourcer og Auto Scaling skal udfører politikker. Det kunne være interessant med mulighed for definition af egne metrikker i CloudWatch, som der kan defineres politikker ud fra. Single point of failure ved placering af funktionalitet på centrale komponenter / services Platformen anvender forskellige availability taktikker. For eksempel er platformen opdelt i zoner i regionen, hvor servicen findes. AWS har flere datacentrer i Europa, USA og Asien og brugeren har mulighed for at vælge, hvordan systemet skal udrulles for at opnå den bedst mulige tilgængelighed. EC2 monitorerer instanser og starter ny instans, hvis en forkert tilstand detekteres Det kræver specifikke kvalitetskrav for en arkitektur anvendt til en cloud service, hvis denne skal udnyttes. For at systemet kan skalere skal der være lav kobling mellem services og de må gerne være uafhængige, hvis muligt. Dermed kan services, som afvikles på platformen, startes og stoppes uden af brugeren bemærker dette. Men der findes mange arkitekturer patterns, som har denne kvalitet, f.eks. Blackboard pattern anvendt i casen.

47 Konklusion Problemstilling: – Hvilke cloud computing teknologier understøtter helt eller dele af teorien? – Hvordan er modenheden af de aktuelle cloud computing teknologier? Metoden og den tilhørende proces for projektet og rapporten har været formaliseret for hver enkelt aktivitet, der skulle udføres for at opnå resultatet og løse problemstillingen defineret. Dette har sikret en objektiv analyse af de 5 udvalgte teknologi kandidater og en balanceret sammenligning, da kandidaten til eksperimentet skulle findes. Dette er det andet rapport produkt baseret på denne metode og konklusion er lignende observationer fra tidligere rapport[12]. Processen kræver, at man afsætter tid til at studere den givne teknologi ellers kan man ikke svare på spørgsmålene, som metoden stiller, f.eks. anvendte prismodeller, teknologi sammensætning, dokumentation og lignende. Den ikke praksis orienteret del af processen bliver valideret i det efterfølgende eksperiment og her skal teknologien bevise, at funktionelle krav og kvalitets krav opfyldes. Resultaterne fundet i den teoretisk og praktiske del viser, at metoden kan anvendes til at synliggøre eventuelle svagheder i teknologien og informere en beslutning om teknologien skal vælges til f.eks. systemudvikling. Metoden og teknologien har givet mulighed for at arbejde med arkitektur design processen. Det viste sig, at den oprindelige broker baseret arkitektur ikke kunne anvendes direkte i platformen uden at foretage yderligere udvikling eller konfiguration. Observationen med dette arbejde er, at problemerne en arkitektur skal løse skal beskrives eksplicit, således den bedste style kan findes. Når en passende style er fundet kan de i omfang mindre design patterns anvendes til at løse problemer objekter eller klasser i mellem. Teknologi kandidaten blev evalueret i det tidligere afsnit ud fra de teoretiske og eksperiment praktiske perspektiver. Indtrykket, som observationer også understøtter, er teknologien findes umoden med hensyn til tilgængelighed og udvikling understøttelse. Amazon giver dog mulighed for vha. detaljeret dokumentation, hyppige opdateringer af software, at finde løsninger på problemer. Platformen har potentiale i et autonomic computing perspektiv. Det kunne også være interessant at kombinere flere cloud teknologier (intercloud) for at dække svagheder mellem teknologierne. For eksempel, så har AWS ikke en service registry eller service til at hjælpe med komponeringen af services. Dette har Azure og man kan dermed kombinere dem. Teknologierne er desuden ikke gamle, den første frigivelse af AWS software fandt sted i 2006 for services og marts 2010 for Java SDK i version 1.0. Prisanalysen viser, at priserne for ressourcerne er meget tæt for cloud udbyderne der tilbyder lignede services f.eks. AWS og Azure. En sidste observation til rapporten er at der ikke findes en definition for begrebet Cloud computing, men flere. Dette giver det indtryk, at da brutto kandidat listen af teknologi produkt blev gennemgået producenter markedsfører produkter under begrebet uden at opfylde kravene til denne. Det er især et indtryk for traditionel hosting provider af server ressourcer, at disse kan benævne produktet ”cloud” uden at have egenskaber som f.eks. auto scaling og en forbrugsafregnet prismodel.

48 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 Market-Oriented Cloud Computing: Vision, Hype, and Reality for Delivering IT Services as Computing Utilities, Buyya et. al., Proceedings of the 2008 10th IEEE International Conference on High Performance Computing and Communications, 2008 An Architectural Approach to Autonomic Computing, IBM Research, White et. al., 2004 Software Architecture in Practice 2nd Ed, Bass, Clements, and Kazman, Addison-Wesley, 2003

49

50

51


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

Lignende præsentationer


Annoncer fra Google