Cloud Computing og availability. Projekt i pålidelighed

Transkript

1 Cloud Computing og availability Projekt i pålidelighed Henrik Lavdal Søren Bardino Kaa Gruppe

2 Indholdsfortegnelse Problemformulering... 4 Metode... 4 Læsevejledning... 5 Cloud computing... 6 Typer af clouds... 7 Public cloud... 7 Private cloud... 7 Hybrid cloud... 8 Typer af services... 8 Infrastructure as a Service (IaaS)... 9 Platform as a Service (PaaS)... 9 Software as a Service (SaaS)... 9 Availability i cloud computing Availability for og imod Clouden kan skalere dynamisk Cloud-udbydere er eksperter Manglende garanti for availability Ingen adgang til clouden ved nedbrud Umuligt at skifte cloud-udbyder Availability taktikker Fault detection Overvåge forbindelsen til clouden Overvåge cloudens services Refleksion Fault recovery Redundans implementeret af cloud-udbyderen Redundans implementeret af kunden Refleksion Fault prevention Overvågning og styringen af en cloud Refleksion Side 2 af 28

3 Konklusion Bibliografi Side 3 af 28

4 Problemformulering Cloud computing begrebet dukker oftere og oftere op i artikler og nyheder omkring IT. Vi synes det kunne være interessant, at finde ud af, hvilke problemstillinger denne type arkitektur er skabt til at løse, og hvilke styrker og svagheder cloud computing har i forhold til pålidelighed. Cloud computing er i bund og grund et eller flere datacentre, der tilbyder skalerbare services døgnet rundt - derfor har vi valgt at se på availability i forhold til pålidelighed. Availability er sandsynligheden for, at et system kan levere en service, når der er brug for det. [Bass, 2003] Et system er pålideligt, hvis dets services stemmer overens med det, der er specificeret [Sommerville, 2004, Chapter 3]. Idet høj availability ofte er en del af specifikationen for clouds, er det meget relevant at se på dette i forhold til pålidelig softwarearkitektur. Ligeledes er der en meget tæt kobling mellem availability og pålidelighed. Høj availability opnås ved at minimere tiden, det tager at genoprette et system efter en defekt. Ved helt at fjerne den fejl der forårsager defekten, minimeres tiden til genopretning af systemet maksimalt. Dermed vil systemets pålidelighed også ofte forbedres, når systemets availability forbedres. Vi vil undersøge: Hvad cloud computing begrebet dækker over. Hvilke tiltag cloud udbyderne benytter for at sikre høj availability. Hvilke alternative muligheder der er for at forbedre en clouds availability. Hvilke muligheder brugerne af clouden har for at minimere effekten af et nedbrud hos cloud udbyderen. Vi vil perspektivere de forskellige muligheder til Bass availability taktikker og forholde os kritiske til dem. Metode Vi vil søge litteratur, der kan give os en forståelse for, hvad begrebet cloud computing dækker over, og hvilke væsentlige aspekter det indeholder. Derudover vil vi søge litteratur, der forholder sig til availability og pålidelighed indenfor cloud computing. I og med at cloud computing Side 4 af 28

5 begrebet er forholdsvist nyt, vil vores søgning primært rette sig mod videnskabelige artikler, internetsider og blogindlæg. Vi vil undersøge, hvilke tiltag der kan bruges eller allerede benyttes til at opnå høj availability og derigennem høj pålidelighed indenfor cloud computing. Med baggrund i Bass availability taktikker [Bass, 2003] vil vi kategorisere og diskutere de forskellige tiltag, der findes for at sikre/forbedre en clouds availability. Udover availability taktikker er der mange andre emner, der kunne behandles i forhold til cloud computing og pålidelighed. Emner som virtualisering, self*architecture, reflective architecture og fault-tolerant systems er også relevante i forhold til cloud computing, men vi har fravalgt at se nærmere på disse temaer for at tilpasse projektets omfang i forhold til den tilgængelige tid. Læsevejledning Afsnittet Cloud computing beskriver begrebet cloud computing samt de mest grundlæggende begreber. Afsnittet Pålidelighed i cloud computing vil indeholde en beskrivelse af hvad der taler for, og hvad der taler imod cloud computing og pålidelighed / availability. Afsnittet Availability taktikker vil indeholde en beskrivelse af de forskellige tiltag, der bliver brugt eller anbefalet til at forbedre de enkelte clouds availability. Derudover vil vi komme med vores vurdering af de enkelte taktikkers værdi. Til sidst vil vi i Konklusion samle op på vores problemformulering. I rapporten definerer vi en kunde som: En virksomhed som benytter en eller flere services hos en cloud-udbyder. Kunden er enten selv slutbruger eller også benyttes cloudens services som en del af virksomhedens eget produkt. Side 5 af 28

6 Cloud computing I dette afsnit beskrives hvad begrebet Cloud Computing dækker over. Derudover afdækkes de forskellige typer af clouds og de forskellige typer af services, en cloud kan udbyde. Cloud computing er efterhånden blevet et begreb, man ikke kan undgå at støde på, hvis man beskæftiger sig med IT. Der findes ikke en klar fælles definition af begrebet cloud computing, og derfor bliver begrebet meget vagt. Dette skyldes, at begrebet bruges i mange forskellige sammenhænge, og at cloud computing er meget opreklameret i tiden. Gartner Group hævede i deres rapport Gartner's Hype Cycle Special Report for 2009 cloud computing fra kategorien Positive Hype til Peak of Inflated Expectations i 2009, så teknologien nu ligger helt i top med hensyn til forventninger [Fenn, et al., 2009]. Der eksisterer mange forskellige definitioner, som hver især ligger vægt på forskellige aspekter. Herunder ses nogle eksempler: In its broadest usage, the term cloud computing refers to the delivery of scalable IT resources over the Internet. [Educause, 2009] "Cloud computing is a kind of computing technique where IT services are provided by massive low-cost computing units connected by IP networks." [Qian, et al., 2009] A cloud is a pool of virtualized computer resources. [Boss, et al., 2007] Ud fra de forskellige definitioner der findes, er det typisk følgende hovedpunkter der lægges vægt på: Clouden kan skalere op eller ned alt efter kunders behov. Clouden sikrer optimalt ressourceforbrug gennem virtualisering. Clouden nedbringer kundens omkostninger idet der betales efter forbrug. Luis M. Vaquero et al. har i en artikel sammenlignet mere end 20 forskellige definitioner og givet deres bud på, hvad cloud computing er: Clouds are a large pool of easily usable and accessible virtualized resources (such as hardware, development platforms and/or services). These resources can be dynamically re-configured to adjust to a variable load (scale), allowing also for an optimum resource utilization. This pool of resources is typically exploited by a pay-per-use model in Side 6 af 28

7 which guarantees are offered by the Infrastructure Provider by means of customized SLAs. [Vaquero, et al., 2008] Denne definition er meget omfattende og rummer de mange forskellige aspekter omkring cloud computing. Vi mener, at den giver et godt indblik i hvad cloud computing er. Typer af clouds Der findes flere forskellige typer clouds, som alle hører ind under begrebet cloud computing. Når begrebet cloud computing benyttes i rapporten, vil der være tale om en public cloud, medmindre typen er angivet særskilt. Figur 1: Tre typer af clouds. [Sohal, 2010] Public cloud Den oprindelige form af cloud computing går under navnet public cloud. Konceptet er, at man som kunde benytter eksterne services, som både kan være applikationer eller infrastruktur, der udstilles som en service af en udbyder. Udbyderen står for at opsætte, administrere, vedligeholde, udbygge og sikre optimal performance af clouden og dens services. Kunden tilgår disse services via forskellige protokoller over internettet. En public cloud bliver ofte udbudt af store virksomheder, der dels har den nødvendige kapital til at drive et stort datacenter og dels også selv har brug for mange IT ressourcer. Af eksempler kan nævnes virksomheder som: Amazon, IBM, Sun, Google og Microsoft. Private cloud En private cloud ejes, administreres og benyttes af en enkelt virksomhed, og der åbnes ikke op for, at andre virksomheder kan benytte den. Årsagen er ønsket om at sikre, at virksomhedens data ikke kommer udenfor virksomhedens firewall og ønsket om at have fuld kontrol over alle Side 7 af 28

8 ressourcerne. Der findes eksperter indenfor cloud computing, der ikke mener, at private clouds falder naturligt ind under cloud computing begrebet [Hamilton, 2010]. I en private cloud mister man nemlig de stordriftsfordele der følger med en public cloud, som fx mulighed for ekstra ressourcer ved peak-workload. Virksomheden skal her også selv betale for hele infrastrukturen i stedet for at dele udgiften til denne med andre. Vi synes heller ikke, at private clouds i sig selv falder naturligt ind under cloud computing begrebet, men i samspil med en public cloud giver det nogle spændende muligheder for at sikre høj availability. Hybrid cloud En hybrid cloud er en kombination, hvor der både benyttes en private cloud og en public cloud. Der benyttes altså både eksterne og interne udbydere af ressourcer. Et eksempel på en kunde til denne type cloud kunne være en virksomhed, der vælger at beholde personfølsomme data internt i virksomhedens egen cloud samtidig med, at en ekstern cloud-udbyder fx betales for at stille computerkraft til store beregninger til rådighed. Typer af services En cloud udbyder services. Disse services kan variere mellem hardware-, platform- og software ressourcer. En cloud kan kategoriseres alt efter hvilke typer af services den udbyder dvs. alt efter hvilket lag de ressourcer der udbydes, befinder sig på. Figur 2: Cloud opdelt i servicelag Udover de tre servicelag er der et tværgående lag, der udbyder forskellige services for clouden. Det er services, der dels understøtter forretningen, fx bestilling af ekstra ressourcer, betaling til udbyderen osv. samt services der understøtter driften af systemerne, fx monitorering og konfiguration af services. Side 8 af 28

9 Infrastructure as a Service (IaaS) Infrastructure as a Service udbyder infrastruktur, dvs. hardwareressourcer som fx lagerplads og processer-kraft. Da dette ofte foregår via virtualisering, har udbyderen mulighed for at omstrukturere disse ressourcer dynamisk efter kundens behov [Vaquero, et al., 2008]. Typisk for denne slags service er, at man afregner på basis af utility computing, hvilket vil sige efter det faktiske forbrug af ressourcer [Wikipedia, 2010]. Platform as a Service (PaaS) Platform as a Service er en platform, hvorpå kunderne kan implementere deres applikationer. Ved denne form for services er hardwarelaget abstraheret væk. Et eksempel på sådan en service er Google App Engine [Google Inc, 2010]. Idet infrastrukturen bygger på virtualisering, opnår man som kunde fordelen med at ressourcerne kan opskaleres ved evt. peakworkload, forudsat at ens egen software understøtter dette. Software as a Service (SaaS) Ved Software as a Service tilbyder serviceudbyderen færdige applikationer som services til kunderne. Kunderne skal altså hverken tænke på ressourcer eller udvikling af software. Typisk er der tale om applikationer, som har en bred interesse og vil blive købt af flere forskellige typer af kunder [Hamilton, 2010]. Det kan fx være applikationer som webservere, tekstbehandlere eller mailklienter. Side 9 af 28

10 Availability i cloud computing Dette afsnit beskriver de forskellige argumenter for og imod, at cloud computing har en høj availability. Der er stor enighed om, at cloud computing er en lovende teknologi og kan vinde stor udbredelse de kommende år ikke mindst pga. muligheden for skalering af ressourcer [Petersen, 2010] og minimeringen af driftsomkostningerne [Educause, 2009; Vaquero, et al., 2008]. Det kræver dog, at cloud computing kan overvinde nogle af de udfordringer, det står overfor. Udfordringerne som der kræves løsninger på ligger primært indenfor sikkerhed [Krill, 2008; Sandal, 2009], pålidelighed og availability samt monitorering [Zhen, 2008; Kim, 2009; Leavitt, 2009]. Availability for og imod Holdningerne til cloudens pålidelighed og availability er delte. En af hovedårsagerne til, at cloud computing ikke er mere udbredt, er netop spørgsmålet om cloudens pålidelighed [Mendler, et al., 2009]. Flere angiver netop pålideligheden som en af de primære grunde til, at de endnu ikke tør benytte sig af cloud computing [Betts, 2010]. Clouden kan skalere dynamisk Hvis kundernes krav til ressourcer ændrer sig, er det i en cloud muligt at tilpasse ressourcerne nemt og hurtigt [Qian, et al., 2009]. Ressourcerne i en cloud kan automatisk skaleres, så de passer til det workload, der er på et givet system på et givet tidspunkt. Det giver en unik mulighed for at kunne håndtere et evt. peak-workload og dette vil være med til at sikre availability netop i pressede situationer, hvor kundens eget IT-system muligvis ville være bukket under [Petersen, 2010]. Cloud-udbydere er eksperter Novikoff påpeger, at pålideligheden er væsentlig bedre for IT-systemerne hos en cloud-udbyder fordi de er specialister indenfor IT og availability og er vant til at holde store datacentre kørende. Derudover har de flere ITressourcer at gøre godt med. Pointen er, at små og mellemstore virksomheder ikke har de samme muligheder, og derfor kan de heller ikke opnå den samme pålidelighed som Cloud-udbyderne kan [Novikoff, 2008]. Side 10 af 28

11 "Cloud providers specialize in particular applications and services, and this expertise allows them to efficiently manage upgrades and maintenance, backups, disaster recovery, and failover functions. As a result, consumers of cloud services may see increased reliability." [Educause, 2009] Vi mener, at Novikoff har ret i denne påstand. Det underbygges af en undersøgelse af Yankee Group Anywhere Enterprise hvor Disaster Recovery / Business Continuation fremstår på tredjepladsen over hovedårsager til, at virksomheder vælger IaaS [Mendler, et al., 2009]. Omvendt har udbyderne ofte ikke den forretningsmæssige viden, og kan derfor have svært ved at vurdere, hvilke data der er vigtigst at få gendannet først efter et evt. nedbrud. Manglende garanti for availability Udbyderne af Cloud Computing undlader at binde sig kontraktligt til servicenedbrud [Mendler, et al., 2009]. Amazon skriver fx i deres brugeraftale i afsnittet med Downtime and Service Suspensions: "In addition to our rights to terminate or suspend Services to you as described in Section 3 above, you acknowledge that: (i) your access to and use of the Services may be suspended for the duration of any unanticipated or unscheduled downtime or unavailability of any portion or all of the Services for any reason, including as a result of power outages, system failures or other interruptions; and (ii) we shall also be entitled, without any liability to you, to suspend access to any portion or all of the Services at any time, on a Service-wide basis". [Amazon Web Services LLC, 2010] Det betyder reelt set, af deres garantier for availability ikke har nogen værdi for kunderne. Dette gælder ikke blot Amazon med hovedparten af cloududbydere. Det er de færreste udbydere, der garanterer availability eller tilbyder økonomisk erstatning ved nedbrud [Novikoff, 2008]. Ingen adgang til clouden ved nedbrud I mange tilfælde er det ikke muligt for kunden at påvirke pålideligheden af den enkelte cloud-service. Det er heller ikke nemt at tage højde for et nedbrud af en service som fx Googles Gmail [Paul, 2009]. Kunderne kan ikke foretage sig ret meget under et nedbrud hos cloududbyderen. De har ikke mulighed for at tage aktiv del i at løse problemet Side 11 af 28

12 men må bare vente [Perez, 2008; Leavitt, 2009]. Dette medfører en del skepsis overfor cloud computing, fordi kunderne ikke selv kan styre den platform, deres services kører på [Leavitt, 2009]. Hvordan skal kunden sikre availability på egne systemer, når udbyderen er nede? Clouden kan blive ramt af strømafbrydelser, service-afbrydelser og systemfejl som fx Microsofts Azure platform der var out-of-service i 22 timer pga. opdatering af operativsystemet [Qian, et al., 2009]. Udover at cloudens services ikke er tilgængelige, har kunderne ofte ikke adgang til deres data. Det at de ikke ved, hvor deres data er gemt, og hvordan de bliver behandlet medfører mindre tiltro til udbyderen, medmindre der er sørget for tilstrækkelig sikkerhed og pålidelighed [Lee, et al., 2009; Murphy, 2008]. Tiltro til udbyderen kræver også, at denne tilbyder mulighed for backup og recovery [Galpin, 2009]. En anden problemstilling er, hvis en cloud udbyder pludselig er nødsaget til at lukke. Hvordan og hvornår kan kunden få sit IT-system op at køre igen, og er det overhovedet muligt? [Erdogmus, 2007] Den manglende kontrol dels med platformen og dels med kundens data, er hovedårsagen til, at over halvdelen af de store virksomheder vælger private clouds frem for public clouds [Mendler, et al., 2009]. Umuligt at skifte cloud-udbyder Manglen på standarder betyder også, at kunderne er fastlåst til en udbyder. Det er ikke muligt, eller i hvert fald meget svært, at flytte sine services imellem de forskellige udbydere [Naone, 2009A; Buyya, et al., 2009; Qian, et al., 2009]. Det er klart, at muligheden for at skifte udbyder ville forbedre pålidelighed på flere fronter. Det vil alt andet lige øge konkurrencen om at skabe den mest pålidelige cloud. Side 12 af 28

13 Availability taktikker Dette afsnit beskriver forskellige taktikker, der kan benyttes indenfor cloud computing til at højne cloudens availability. En taktik er en eller flere handlinger/beslutninger, der skal til for at opnå et bestemt mål. Her er målet et opnå en høj availability. Bass beskriver tre forskellige kategorier indenfor taktikker til at højne et systems availability: Fault detection, Fault recovery og Fault prevention [Bass, 2003]. De enkelte tiltag vi har fundet i forbindelse med gennemgang af litteraturen vil blive kategoriseret ud fra Bass availability taktikker og vurderet i forhold til deres værdi. Bass benytter begreberne fault og failure. En fault er en fejl i applikationens specifikation, design, implementation eller en afvigelse fra en ønsket eller forventet tilstand. En fault vil som oftest resultere i en failure, medmindre der gøres noget aktivt for enten at rette op på fejlen eller skjule den. En failure udspringer af en fault. En failure kan observeres af systemets bruger, det kan en fault ikke. Fault detection Fault detection omhandler teknikker til at detektere faults. Det handler om at opdage en fault hurtigst muligt. Først når faulten er detekteret, kan der gøres noget aktivt for at undgå, at faulten eskalerer til en failure, som evt. gør systemet utilgængelig. Hvis faulten allerede har udviklet sig til en failure, der gør at systemet ikke er tilgængelig, skal der sættes gang i en recovery-proces, så systemet kan komme op at køre igen. Bass beskæftiger sig med tre taktikker indenfor dette område. Ping/echo, hvor klienten, der ønsker at overvåge en komponent, sender beskeder til komponenten og derefter forventer at få en respons tilbage fra komponenten. Heartbeat, hvor komponenten selv sender beskeder ud med fast tidsinterval for at indikere dens status. Exceptions, hvor evt. faults håndteres via kodelogik. Exceptionstaktikken ser vi bort fra, da vores fokus omkring cloud computing ligger på et højere niveau end selve applikationskoden. Side 13 af 28

14 Overvåge forbindelsen til clouden Et grundlæggende problem i cloud computing er, at services afvikles eksternt, og derfor kræves der en stabil forbindelse til datacentrene der udbyder cloud-services [Santo, 2008; Leavitt, 2009]. At en kunde kan få problemer med forbindelsen til clouden er ikke et problem, der skal løses af datacentrene. Det er op til de enkelte kunder selv at sikre en pålidelig forbindelse. En mulighed er at benytte en fault detection taktik til at overvåge forbindelsen til clouden. Dette giver kunden mulighed for at reagere, hvis der opstår problemer med forbindelsen til clouden. Overvåge cloudens services En ting er at overvåge selve internetforbindelsen til en cloud, et andet aspekt er at overvåge hvorvidt servicen i en cloud er available. Fornuftige API er udstillet af service-udbyderne er en af de ting Mukul Kumar efterlyser i sit blogindlæg om cloud availability [Kumar, 2008]. Hans pointe er, at hvis der ikke udstilles et API til at monitorere en given service, har brugeren af servicen ingen mulighed for at opdage evt. komplikationer og reagere herefter. Kumars kritik går endvidere på, at hvis en cloud-udbyder har en statusside, er det typisk en statisk side, som først opdateres efter et evt. nedbrud er overstået. Skype er et eksempel på en udbyder, der har implementeret overvågning, og via en hjemmeside viser status på deres SaaS. Det er oplagt, at de benytter taktikken heartbeat til dynamisk at holde siden opdateret. Figur 3. Skype-overvågning i form af heartbeat [Skype, 2010] Amazon har benyttet en anden monitoreringstaktik. De udstiller et API i form af en webservice, der giver mulighed for at implementere en ping/echo taktik, hvor brugeren får mere kontrol over monitoreringen. Web-servicen Amazon CloudWatch [Amazon Web Services, 2010], har bl.a. interfaces til at overvåge ressourceforbrug og performance. Side 14 af 28

15 Refleksion Generelt har der ikke været meget fokus på kundens overvågning af en cloud-service i det materiale vi har arbejdet med. En af grundene til dette skyldes muligvis, at cloud computing begrebet og overvågning af cloudservices er to ting, der forretningsmæssigt til dels kan virke modstridende. Når man som kunde vælger en cloud-udbyder, må det være ud fra devisen om, at udbyderen kan udføre en bestemt form for service billigere og/eller bedre end kunden selv. Hele cloud-konceptet lægger altså op til, at man som kunde har tillid til, at en cloud-udbyder påtager sig et ansvar og yder en tilfredsstillende service. Hvis man som kunde har truffet denne beslutning, kan det virke lidt underligt at bruge de ressourcer der er sparet til at etablere en overvågning af udbyderen/servicen. Ideen er, at hvis der opstår problemer, tager cloud-udbyderen hånd om disse. Vores opfattelse er dog, at hvis cloud-udbyderene skal gøre sig forhåbninger om at få store virksomheder til at benytte deres cloud, kræver det en fornuftig mulighed for monitorering fra kundens side. Vi tror ikke på at virksomheder er villige til at tage skridtet fuldt ud og benytte cloud computing, hvis ikke de har mulighed for fuld monitorering af deres kritiske applikationer. Vi mener derfor, at monitorering vil få en større rolle, efterhånden som cloud computing modnes. Med hensyn til heartbeat og ping/echo taktikkerne mener vi, at et vigtigt aspekt er, hele tiden at få brugbare service/ressource-data og ikke bare information om, at servicen er tilgængelig eller ej. Hvis man som kunde præventivt skal kunne tage hånd om problemer inden nedbrud, kræver det, at man har så mange status-oplysninger for en service som muligt. Umiddelbart ser vi den største mulighed for dette i den løsning Amazon har implementeret i form af deres CloudWatch service. Sidst men ikke mindst er det værd at huske på, at kæden ikke er stærkere end det svageste led, hvorfor det er vigtigt, at kunden sørger for at sikre sig en eller flere pålidelige forbindelser til clouden. Fault recovery Fault recovery er dels taktikker der gør det muligt at gendanne en komponent der er ramt af en fault og dels taktikker til at genindsætte komponenten igen. Bass nævner følgende taktikker indenfor gendannelse af en komponent. Voting handler om at samme input behandles parallelt af hver sin proces. De enkelte processor må gerne have forskellige implementationer Side 15 af 28

16 men samme specifikation. Voteren kan derved opdage hvis en eller flere processor afviger fra de andre og udelukke disse. Aktiv redundans er den form der giver mulighed for højest availability. Her udfører alle redundante komponenter det samme stykke arbejde parallelt. Passiv redundans er den næstbedste form. Her står en komponent i standby og skal ved nedbrud af den primære ressource først sikre sig, at den befinder sig i den rigtige tilstand. Først derefter kan den tage over fra den primære ressource. En spare er en IT platform der kan erstatte mange forskellige komponenter. Den skal startes op, konfigureres og synkroniseres. Vi synes ikke, at spare set i forhold til cloud computing formår at skabe grundlag for en tilfredsstillende availability, og derfor ser vi bort fra denne taktik. Disse taktikker er afhængige af at den fejlede komponent kan genindsættes hvorfor der også eksisterer forskellige taktikker til at dække dette behov. Shadow operation, hvor komponenten kører i shadow mode indtil der er tillid til at den fungerer korrekt. State resynchronization som omhandler hvordan man efter et nedbrud får tilstanden på den redundante enhed opdateret dette gælder både ved aktiv og passiv redundans. Checkpoint / rollback er med til at sikre at enheden hele tiden er i en konsistent tilstand. Vi behandler ikke de tre genindsættelses-taktikker yderligere, idet vi ingen information har omkring hvilke taktikker udbyderne benytter sig af. Men at taktikkerne bliver brugt er der ingen tvivl om. Redundans implementeret af cloud-udbyderen Hvis de redundante maskiner er placeret i samme datacenter, risikerer de at blive single point of failure, hvis der opstår en fault der rammer hele datacentret. Det kunne fx være jordskælv, strømafbrydelser eller andre katastrofer. En løsning kan være, at cloud-udbyderen selv etablerer datacentre på forskellige lokationer rundt omkring i verden [Buyya, et al., 2009] og derved sikrer mulighed for en højere availability. Amazon er et eksempel på en cloud-udbyder, der tilbyder denne form for redundans, i form af et koncept de kalder Amazon Avaliability Zones [Amazon Inc, 2010]. De har maskiner placeret fysisk isoleret fra hinanden i Side 16 af 28

17 forskellige geografiske zoner. Samtidig med at dette koncept giver mulighed for en højere availability, giver det dog også udfordringer omkring det at synkronisere data mellem de forskellige zoner. I og med at zonerne er placeret med god afstand til hinanden, opstår der dels risiko for network latency mellem zonerne, samt det faktum at kunden skal betale for den ekstra trafik der finder sted mellem zonerne i form af synkronisering [Thorsten, 2008]. Redundans implementeret af kunden F. Andy Seidl fokuserer på redundans på tværs af clouds. Han hylder cloud computing men spørger samtidig, hvorfor det at bruge cloud computing skulle betyde, at man skal kassere alt det, man generelt ved om at bygge pålidelige systemer [Seidl, 2008]. Han foreslår, at man som bruger af en service opbygger sin arkitektur ved at benytte flere forskellige cloududbydere. På den måde tilfører man selv redundans og sikrer sig dermed imod, at ens services bliver utilgængelige ved et nedbrud hos en udbyder. Man skal være opmærksom på, at det kan give udfordringer at implementere redundans imellem forskellige clouds. En af udfordringerne er fx, at der ikke er standardiserede interfaces udbyderne imellem [Naone, 2009A]. Det gør det svært at benytte forskellige cloud-udbydere som standby for hinanden. Ofte vil det være nødvendigt at udvikle en klient, der kan benytte flere forskellige interfaces/protokoller. Open Cloud Consortium arbejder dog på et fælles interface / åbent framework [Brodkin, 2009]. I forbindelse med aktiv redundans nævner Bass bl.a., at aktiv redundans fx kan benyttes i form af dublering af netværksressourcer, så der er mere end én kommunikationskanal, hvis det er vigtigt at kunne tilgå distribuerede ressourcer [Bass, 2003]. Hvis man som kunde ikke har en stabil og pålidelig internetforbindelse, gør det ikke den store forskel, at der er implementeret fornuftig redundans i selve clouden. Brugeren bør altså sikre tilgangen til clouden bedst muligt, hvilket fx kan gøres med en alternativ internetudbyder og på den måde sikre, at forbindelsen til clouden ikke bliver en single point of failure. Både Santo og Naone har et løsningsforslag der går på at kombinere hybrid cloud computing med en form for passiv redundans [Santo, 2008; Naone, 2009B]. Ideen er, at man benytter en public cloud men samtidig har en redundant kopi lokalt, dvs. en passiv private cloud til brug i fejlsituationer. I tilfælde af nedbrud på en public cloud-service, kan der skiftes over til en tilsvarende eller neddroslet service på den private cloud. Den sekundære service vil ofte være en reduceret kopi af den primære Side 17 af 28

18 service, fordi der er færre ressourcer til rådighed lokalt. Den lokale service vil derfor ofte kun udbyde de mest basale og vigtigste funktioner. Refleksion Vi ser generelt både aktiv og passiv redundans på tværs af clouds som gode måder til at hæve availability på en service, der afvikles via cloud computing. Den passive redundans har den ulempe, at den er lidt langsommere end den aktive til at kunne tage over ved et nedbrud. Til gengæld har den en stor fordel i form af pris, i og med at mange cloudservices afregnes efter det egentlige forbrug af ressourcer. Idet en standbyservice har et minimalt ressourceforbrug, giver det mulighed for, at have denne kørende uden at det har de store omkostninger for kunden. Ved et evt. nedbrud, hvor den sekundære cloud tager over, kan der drages fordel af at ressourcerne automatisk kan opskaleres til det nye behov. Vi ser en stor forskel på hvilken type af cloud-service, der giver mulighed for at benytte redundans. SaaS er som tidligere beskrevet en service i form af en applikation, som udstilles af en cloud-udbyder. I disse tilfælde ejer cloud-udbyderen som oftest applikationen, hvilket gør, at man som bruger ikke kan kræve at den også skal driftes af en anden cloududbyder. Hvis man bevæger sig ned på PaaS eller IaaS, får kunden mere indflydelse og dermed bedre muligheder for at træffe valg om redundans. Vi vurderer, at det er nemmest og billigst at implementere redundans på IaaS-laget, da der her er tale om virtuelle hardware-ressourcer. Et nedbrud og recovery vil dermed ikke give de samme behov og udfordringer, som der vil være ved at ved at få synkroniseret software tilstanden på PaaS og SaaSniveau. I teorien lyder det flot med mulighed for redundans både internt i cloud en og eksternt i form af brugen af flere forskellige cloud-udbydere. Vi ser dog den manglende fælles standard som en stor udfordring for at skabe redundans på tværs af udbyderne. Hvis der fandtes et fælles interface, var det dels nemmere at kommunikere med flere forskellige udbydere, og samtidig kunne det hjælpe med til at løse den hårde binding, der opstår til den valgte udbyder. For små og mellemstore virksomheder tror vi, at den økonomiske gevinst forsvinder, hvis virksomheden ønsker at implementere redundans på tværs af udbyderne, så længe der endnu ikke findes fælles standarder. Omvendt kan det være interessant for virksomheder, der netop ønsker at skabe redundans i kritiske dele af et fault-tolerant system, hvor diversitet er en del af strategien. Sommerville har tidligere beskrevet hvordan diversitet på alle tre niveauer, hardware, platform og software er et vigtigt aspekt når man ønsker at benytte N-version programing og Side 18 af 28

19 recovery blocks [Sommerville, 2004, Chapter 20]. I sådan et tilfælde kan kunden vende ulempen med de manglende standarder og forskellige implementationer cloud-udbyderne imellem til en fordel ved at benytte en voting taktik. På samme måde som tidligere beskrevet omkring monitorering, ser vi spørgsmålet omkring cloud-redundans som en overvejelse kunden må træffe på grundlag af, hvor kritisk en service der er tale om, og hvor stor en tiltro der er til cloud-udbyderen. Det afhænger altså af hvor store konsekvenser det får for kunden, hvis servicen ikke er tilgængelig hele tiden. Redundans på tværs af cloud-udbyderne kan i nogle tilfælde være en fornuftig løsning. Man skal blot være opmærksom på, at det medfører yderligere omkostninger, dels at benytte flere udbydere og dels selv at udvikle en applikation der kan håndtere flere clouds. Det er altså en overvejelse værd, hvorvidt løsningen stadigvæk er rentabel. [Novikoff, 2008] Hvis man som kunde ikke ønsker at benytte ressourcer til at etablere redundans på tværs af cloud-udbyderne, men stadigvæk har fokus på høj availability mener vi, ligesom Kontino [Kontio, 2009], at man bør vælge cloud-udbyder efter, om selve udbyderen har implementeret en fornuftig redundans indenfor selve clouden. Vi har dog erfaret, at det kan være svært at finde information omkring hvordan cloud-udbyderne hver især har valgt at implementere redundans indenfor deres clouds. I så fald må man nøjes med at se på de kontrakter, fx i form af de SLA-aftaler, en udbyder er villig til at tilbyde. Det giver et billede af, hvor højt cloud-udbyderen prioriterer availability. Fault prevention Fault prevention går i al sin enkelthed ud på at forebygge failures ved at reagere i tide på (forventede) faults. Det er vigtigt at holde det adskilt fra fault avoidance, hvis fokus er at skabe fejlfri software. Removal from service er en taktik hvor en komponent fjernes fra et kørende system. Komponenten kan derefter tages under behandling for at forbygge imod forventede fejl. Bass nævner selv genstart af en komponent som en metode for at undgå at komponenten fejler pga. memoryleaks. Transaktionsstyring er samlingen af flere operationer i en transaktion med mulighed for at tilbageføre samtlige operationer, hvis blot en enkelt operation fejler, eller hvis flere operationer forsøger at opdatere samme ressource samtidig. Side 19 af 28

20 En process monitor overvåger de aktive processor, og derved kan en fault i en proces opdages i tide. Derefter kan monitoren fjerne den aktuelle proces og erstatte den med en ny instans, som initialiseres til en passende tilstand (state). Set i forhold til cloud computing er process monitor en væsentlig taktik. Dette fordi clouden afvikler mange processor, hvis fejlrate oftest er ukendt. Det er derfor væsentlig at holde øje med de aktive processor for netop at kunne udskifte en proces, i stedet for at risikere at clouden går ned. Isolation nævnes også ofte i forhold til cloud computing, om end Bass ikke nævner dette. Begrebet dækker over, at applikationer isoleres i hver sin sandkasse og dermed opnås den fordel, at en failure i en applikation ikke påvirker andre applikationer. I cloud computing er det virtualiseringen, der medfører at applikationerne isoleres fra hinanden. Overvågning og styringen af en cloud Song, et al. har set på den server, der overvåger og styrer cloudens processor. Traditionelt har der i et netværk været en enkelt server der fungerede som monitor. Det har fungeret godt, så længe der ikke har været flere tusind processor, der skulle overvåges og styres. Udfordringen i forhold til clouds er dels, at monitoren ikke dynamisk kan skalere op på samme måde som resten af clouden, og dels at den bliver kandidat til single point of failure. Løsningen kan være at lave flere monitorer, der deles om opgaven. Altså et distribueret redundant monitor system. Redundant for at sikre availability [Song, et al., 2009]. En anden problemstilling ved overvågning er, hvis monitoren og de services den overvåger afvikles på hardware i samme datacenter. Hvis datacentret rammes af fx strømnedbrud vil monitoren også gå ned. Ved at lade overvågningen af cloudens services køre fra et andet datacenter, end det hvor den egentlige service udbydes fra, forbedres muligheden for at opdage og agere på problemer [Novikoff, 2008]. En mulighed er også at lade kunderne selv drive en form for monitor. Hvis kunderne løbende informeres om cloudens tilstand, har de mulighed for at reagere ved fx at skifte til en anden cloud - hvis de er bekymrede for om clouden fortsat kan yde den nødvendige service. Situationen pt. er, at der mangler API er til live monitorering af en cloud og dens services som beskrevet under Fault detection. Med bedre monitorering vil man som kunde have mulighed for at reagere inden tingene går galt [Kumar, 2008]. Generelt med hensyn til at forebygge fejl mener Atkins, at udbyderne af cloud services med tiden vil se nogle fælles problemstillinger for de Side 20 af 28

21 applikationer, der benytter clouden. Ved at lade cloudens services tage hånd om disse problemstillinger, kan applikationernes pålidelighed øges [Atkins, et al., 2005]. Hoff foreslår, at man benytter sig af en caching proxy foran cloudservicen [Hoff, 2008]. Ideen med en caching proxy vil være at lade requests til clouden gå igennem en proxy, der cacher servicens respons. I tilfælde af et cloud-nedbrud, skal proxyen tage over og svare på forespørgsler i stedet for clouden. Refleksion Transaktionsstyring er meget relevant dels ved tilgang til de samme data, og dels i forhold til kommunikation mellem komponenter. I litteraturen er transaktionsstyring ikke nævnt i forhold til cloud computing. Det skyldes formentlig det faktum, at komponenterne er isolerede fra hinanden gennem virtualisering, og derfor er transaktionsstyring primært et emne for den enkelte applikation. Removal from service kræver et vist kendskab til de aktive processor, da det beror på, hvorvidt man forventer en fejl. Især i forhold til SaaS vil det være oplagt at udbyderne med tiden vil få et indgående kendskab til deres services, og dermed kan reagere på et så tidligt tidspunkt, at en failure undgås. Derigennem højnes servicens availability. Vi mener derfor at Atkins har delvis ret i hans teori. Set i forhold til IaaS er kundernes behov noget forskellige. Vi mener, at det her primært er kunderne selv, der kan forbedre deres systemers pålidelighed, forudsat at datacentrene har godt styr på hardware og virtualisering. Monitorering af cloudens services er vigtigt, idet det er meget væsentligt at sikre at disse hele tiden fungerer. Songs forslag, omkring at benytte et distribueret system til overvågning og styring, virker meget relevant, og det er tydeligt, at der er tænkt over systemets availability. Vi savner dog en nærmere beskrivelse af hvordan overvågningen og styringen af en cloud internt fungerer i dag. Benytter udbyderne rent faktisk blot en enkelt stor server til dette? Det virker ikke sandsynligt. Derfor er Songs forslag meget relevant, om end vi savner nogle fakta omkring styringen af clouds til at holde det op imod. Hvordan reagerer clouden, når den opdager, at en process er ramt af en failure? Taktikken caching proxy har nogle klare begrænsninger i forhold til hvilken type services clouden udbyder. Det vil ikke fungere for en IaaS, da det ikke giver mening at cache hardware-ressourcer. For at dette skal kunne fungere, skal der være tale om en meget simpel service, som udstiller noget Side 21 af 28

22 der kan caches. Et oplagt eksempel vil være en web-service som udstiller statisk indhold. Igen må vi konstatere, at hvis man arbejder med en service, der er mere dynamisk eller har at gøre med en mere kompleks applikation udbudt som service, vil en caching proxy ikke være til stor gavn. Vi har derfor svært ved at se denne løsning i brug. Side 22 af 28

23 Konklusion Cloud computing begrebet bliver brugt i mange forskellige sammenhænge og dækker meget bredt. Der findes flere gode definitioner af begrebet [Vaquero, et al., 2008], men desværre misbruges begrebet også tit, hvilket er med til at skabe forvirring. Manglen på standarder indenfor cloud computing gør det heller ikke nemmere at præcisere begrebet. Sidst men ikke mindst er der heller ikke enighed om hvorvidt fx private clouds bør høre ind under begrebet cloud computing. Vi mener at Vasquero, et al. har en god definition af begrebet, der sammenholdt med hvilken type cloud og hvilken type services clouden udbyder giver en taksonomi, der gør det muligt at præcisere, hvad det er, der egentlig tales om. De forskellige udbyder beskriver hver især deres clouds som værende higly available, uden dog at komme nærmere ind på hvilke taktikker de benytter for at sikre dette. Modsat viser både blogs og nyhedsindlæg, at det rammer mange slutbrugere, når en cloud er nede. Af samme grund medfører det også stor frustration hos cloudens kunder, fordi de sjældent kan foretage sig noget for at afhjælpe problemet. Der er dog flere forskellige mulige tiltag, der kan benyttes for at sikre høj availability af en cloud. Hovedparten af disse tiltag bygger ovenpå eksisterede viden omkring taktikker til at sikre høj availability, hvorfor de enkelte tiltag passer godt i i Bass taksonomi. Dette må siges, at være positivt idet Bass taktikker er velkendte og afprøvede, hvorfor Seidl også rammer plet når han skriver: But why does using cloud computing require that you discard everything you know about building reliable systems? [Seidl, 2008] Kundernes muligheder for at påvirke en cloud, er meget forskellige alt efter hvilken type cloud og hvilken type service, der er tale om. Grundlæggende handler det om at få afdækket kundes behov. Hvilke services han har brug for, hvor høj en availability han har brug for, samt hvor længe han kan klare at være ude af drift. Her er det dog værd at huske, at cloud-udbyderne i deres SLA er ikke giver de store garantier hvilket vi ser som et stort problem i forhold til udbredelsen af public clouds i forhold til kritiske systemer. Cloud computing og availability er et yderst relevant emne. Der er dog behov for flere dybdegående artikler om cloud computing samt at teknologien modnes. Der mangler generelt beskrivelser af hvad udbyderne gør for at sikre availability. For at sikre udbredelsen af cloud computing er der brug for garantier fra udbyderne i forhold til availability og flere fælles Side 23 af 28

24 standarder. Vi er overbevist om at vi i fremtiden vil se flere kritiske systemer liggende i clouds, idet vi kan konkludere, at de allerede kendte availability taktikker med fordel kan benyttes til at sikre en høj availability. Side 24 af 28

25 Bibliografi Amazon Inc Elastic Load Balancing. [Online] [Cited: Februar 24, 2010.] Amazon Web Services Amazon CloudWatch. Amazon. [Online] [Cited: Febuar 28, 2010.] Amazon Web Services LLC Amazon Web Services Customer Agreement. Amazon. [Online] Februar 9, [Cited: Februar 24, 2010.] Atkins, D. E., et al Appendix A: More about What is Cyberinfrastructure?. s.l. : National Science Foundation, Bass Software Architecture in practice 2nd Edition. s.l. : Addison- Wesley, Betts, Mitch Cloud computing still raises security, reliability concerns. Computerworld. [Online] Januar 04, [Cited: Marts 10, 2010.] _Resistance. Boss, G., et al Cloud Computing (IBM). s.l. : IBM Corporation, Brodkin, Jon Consortium tackles cloud computing standards. ITworld. [Online] Januar 08, [Cited: Marts 10, 2010.] Buyya, R., et al Cloud computing and emerging IT platforms: Vision, hype, and reality for delivering computing as the 5th utility. Future Gener. Comput. Syst. Juni 2009, Vol. 25, 6. Educause Things You Should Know About Cloud Computing Erdogmus, Hakan On-Demand Enterprise Services: Where s the catch. s.l. : IEEE Software, Fenn, J., Raskino, M. and Gammage, B Gartner's Hype Cycle Special Report for s.l. : Gartner, Inc., special pdf. Side 25 af 28

26 Galpin, M Realities of open source cloud computing, Part 1: Not all clouds are equal. IBM - developerworks. [Online] April 07, [Cited: 02 24, 2010.] Google Inc Google App Engine. [Online] [Cited: Februar 24, 2010.] Hamilton, J Private Clouds Are Not The Future. James Hamilton's Blog. [Online] Januar 17, [Cited: Februar 24, 2010.] ture.aspx. Hoff, T Strategy: Front S3 with a Caching Proxy. High Scalability. [Online] Juli 20, [Cited: Februar 24, 2010.] Kim, Won Cloud Computing: Today and Tomorrow. Journal of Object Technology Klems, M., Nimis, J. and Tai, S Do Clouds Compute? A Framework for Estimating the Value of Cloud Computing. s.l. : Springer-Heidelberg, Kontio, M Architectural manifesto: An introduction to the possibilities (and risks) of cloud computing. s.l. : IBM Corp., Krill, Paul Her er de store udfordringer ved cloud computing. Computerworld. [Online] November 28, [Cited: Marts 06, 2010.] Kumar, M Cloud Availability. Mukul Kumar's Blog. [Online] [Cited: Februar 24, 2010.] Leavitt, N Is Cloud Computing Really Ready for Prime Time? Computer 42. 1, Januar 2009, pp Lee, J. Y., et al A Quality Model for Evaluationg Software-as-a-Service in Cloud Computing. Software Engineering Research, Management and Applications. 2009, Mendler, C. and Poon, A Pinning Down Cloud Computing. Slideshare. [Online] [Cited: februar 24, 2010.] Side 26 af 28

27 Murphy, P Where there's hype, there's fire? Murphy. [Online] September 9, [Cited: Februar 24, 2010.] Naone, E. 2009A. Industry Challenges: The Standards Question - Security and reliability aren't the only problems for cloud users and providers. Technology Review. [Online] 2009A. [Cited: Februar 24, 2010.] Naone, E. 2009B. Technology Overview: Conjuring Clouds. Technology Review. [Online] Juli/August 2009B. [Cited: Februar 24, 2010.] Novikoff, E Reliability and Cloud Computing. ENKI - Managed Cloud Computing. [Online] [Cited: Februar 24, 2010.] Paul, Ian Google Outage Lesson: Don't Get Stuck in a Cloud. PCWorld. [Online] Maj 15, [Cited: Marts 04, 2010.] _stuck_in_a_cloud.html. Perez, J. C Google Apps Admins Jittery About Gmail, Hopeful About Future. PC World. [Online] August 15, [Cited: Februar 24, 2010.] mins_jittery_about_gmail_hopeful_about_future.html. Petersen, Rune Skat tættere på skyen efter nyt nedbrud. Computerworld. [Online] Marts 05, [Cited: Marts 06, 2010.] Qian, Ling, et al Cloud Computing: An Overview. Cloud Computing. s.l. : Springer Berlin / Heidelberg, 2009, Vol. 5931, pp Sandal, Jesper Stein Cloud computing kan være et mareridt for itsikkerhed. Version2. [Online] April 22, [Cited: Marts 06, 2010.] Santo, M Gmail Outage Shows "The Cloud" Still Has a Slightly Tarnished Lining. Technology Expert. [Online] [Cited: Februar 24, 2010.] Side 27 af 28

28 Seidl, F. A Cloud Computing and Reliability. [Online] [Cited: Februar 24, 2010.] Skype heartbeat.skype.com. Heartbeat. [Online] Skype, [Cited: Marts 5, 2010.] Sohal, H. S Cloud Computing. Harbhag Singh Sohal - You have to BELIEVE. [Online] [Cited: Marts 9, 2010.] Sommerville. 2004, Chapter 20. Critical system development. Software Engineering 7th Ed. s.l. : Addison-Wesley, 2004, Chapter 20. Sommerville. 2004, Chapter 3. Critical systems. Software Engineering 7th Ed. s.l. : Addison-Wesley, 2004, Chapter 3. Song, S., Ryu, K. D. and Silva, D. D Blue Eyes: Scalable and reliable system management for cloud computing pp Thorsten Setting up a fault-tolerant site using Amazon s Availability Zones. RightScale Blog. [Online] [Cited: Febuar 28, 2010.] Vaquero, L. M., et al A Break in the Clouds: Towards a Cloud Definition. SIGCOMM Comput. Commun. Rev. 39, 1. December 2008, pp Vouk, M.A Cloud Computing Issues, Research and Implementations. 30th International Conference on Information Technology Interfaces Wikipedia Cloud Computing. Wikipedia. [Online] [Cited: Februar 24, 2010.] Zhen, Jian Five Key Challenges of Enterprise Cloud Computing. Cloud Computing Journal. [Online] November 16, [Cited: Marts 06, 2010.] Side 28 af 28