Linköpings universitet SE–581 83 Linköping
Linköpings universitet | Institutionen för datavetenskap
Examensarbete på grundnivå, 16hp | Datateknik
2017 | LIU-IDA/LITH-EX-G--17/083--SE
Sammansättning av ett privat
moln som infrastruktur för
ut-veckling
–
Kandidatarbete
Putting together a private cloud as infrastructure for
deve-lopment
–
Final thesis
Alexander Ernfridsson
Handledare: Mikael Asplund Examinator: Simin Nadjm-Tehrani
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admi-nistrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannenslitterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circumstan-ces. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchang-ed for non-commercial research and unchang-educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
c
Sammanfattning
Idag är det vanligt att hantera, beskriva och konfigurera sin datainfrastruktur såsom pro-cesser, serverar och miljöer i maskinläsbara konfigurationsfiler istället för fysisk hårdvara eller interaktiva konfigureringsverktyg. Automatiserad datainfrastruktur blir mer och mer vanligt för att kunna fokusera mer på utveckling och samtidigt få ett stabilare system. Det-ta har gjort att anDet-talet verktyg för automatisering av daDet-tainfrastruktur skjutit i höjden det senaste årtiondet. Lösningar för automatisering av olika typer av datainfrastrukturer har blivit mer komplexa och innehåller ofta många verktyg som interagerar med varandra.
Det här kandidatarbetet jämför, väljer ut och sätter ihop existerande plattformar och verktyg och skapar ett privat moln som infrastruktur för utveckling. Detta för att effek-tivera livscykeln för en serverbaserad runtime-miljö. En jämförelse av molnplattformarna OpenStack, OpenNebula, CloudStack och Eucalyptus baserad på litteratur, lägger grun-den för molnet. Molnplattformen kompletteras därefter med andra verktyg och lösningar för att fullborda livscykelautomatiseringen av runtime-miljöer. En prototyp av lösningen skapades för att analysera praktiska problem.
Arbetet visar att en kombination av OpenStack, Docker, containerorkestrering samt konfigureringsverktyg är en lovande lösning. Lösningen skalar efter behov, automatiserar och hanterar verksamhetens konfigurationer för runtime-miljöer.
Innehåll
Abstract iii Innehåll iv Figurer vi Tabeller vii 1 Introduktion 1 1.1 Syfte . . . 2 1.2 Problemformulering . . . 2 1.3 Metodsammanfattning . . . 3 1.4 Avgränsning . . . 3 1.5 Rapportöversikt . . . 4 1.6 Språkbruk . . . 4 2 Teori 5 2.1 Infrastruktur i kod . . . 5 2.2 Automatisering av infrastruktur . . . 5 2.3 Virtuell miljö . . . 6 2.4 Molntjänster . . . 92.5 Container eller hypervisor i molnet . . . 12
2.6 Tidigare prestandajämförelser av hypervisors . . . 13
2.7 Containerlösningar i OpenStack . . . 14
3 Metod 16 3.1 Jämförelsestudie av IaaS plattformar med hjälp av litteratur . . . 16
3.2 Prototyp . . . 19 4 Förstudie av molnplattformar 20 4.1 Nyckelfunktioner . . . 20 4.2 Interoperabilitet . . . 20 4.3 Skalbarhet . . . 21 4.4 Autentisering . . . 21 4.5 Användarvänlighet . . . 21 4.6 Prestanda . . . 21
4.7 Aktivitet och Community . . . 22
4.8 Sammanfattning . . . 23
5 Val av molnlösning 24 5.1 Molnplattform . . . 24
5.2 Hypervisor . . . 24
5.4 Konfigureringsverktyg och reproducering . . . 25
5.5 Summering . . . 25
6 Prototyp: analys av OpenStack 27 6.1 Problem vid installationsförfarandet av OpenStack . . . 29
6.2 Koppling mellan tjänster . . . 31
6.3 Intrycket av OpenStacks installationsmanual . . . 31
6.4 Praktisk kravuppfyllnad . . . 31
7 Diskussion 34 7.1 Metod . . . 34
7.2 Molnlösning . . . 35
7.3 Prototyp . . . 35
7.4 Arbetet i bredare kontext . . . 36
Figurer
2.1 Exempel på hur ett versionshanteringsverktyg kan användas. . . 6
2.2 Hypervisor vs container lösning . . . 7
2.3 Molntjänster . . . 9
2.4 Exempel på olika IaaS stackar . . . 13
4.1 Community statistik för IaaS-plattformarna . . . 22
5.1 Övergripande arkitektur av den valda molnlösningen . . . 26
Tabeller
2.1 Programvaror för virtualisering i deras tillhörande kategorier . . . 8
2.2 Molnplattformar att studera . . . 10
2.3 Förstuduie av molnplattformar . . . 12
3.1 Poängsystem för evaluering utav de valda molnplattformarna . . . 18
4.1 Summering av litteraturstudie av molnplattformar . . . 23
1
Introduktion
Denna rapport sammanfattar ett examensarbete inom programmet högskoleingenjör i data-teknik (16hp) vid Linköpings universitet. Arbetet har utförts på Ida Infront i Linköping. Ida Infront är ett IT-företag som utvecklar dokument- och ärendehanteringssystem vilka är en klient till server lösning.
1.0.1
Bakgrund
Ida Infront arbetar i olika team när de utvecklar sina produkter och behöver mycket hård-vara och mjukhård-vara för att fungera effektivt. För att testa en produkt används bland annat en runtime-miljö (RTE) som innehåller all underliggande mjukvara som behövs för att köra produkten. En RTE består i det här sammanhanget typiskt av ett operativsystem, en Java-miljö, en databas, en applikationsserver samt en version av företagets produkt. RTE:er sätts idag upp manuellt, både lokalt av utvecklare vid arbetsplatserna och på delade servrar av driftpersonal. Dessa plockas fram vid behov eftersom de inte alltid används för att spara på resurser.
1.0.2
Motivering
Konfigurationsfel har, i allmänhet, blivit en av de största orsakerna för systemfel, på grund av att system blivit mer komplexa och innehåller mer konfiguration än förr [1]. Konfiguration av komplex mjukvara består oftast av hundratals rader av konfigurationsparametrar och mjuk-vara är oftast ihopkopplade med mjuk-varandra vilket leder till konfigurationsberoenden mellan olika mjukvaror vilka kan vara dåligt dokumenterade och designade [1]. Z. Yin et al. [2] visar att 27 % av alla supportärenden från konsumenter vid ett stort databas och lagringsföretag i USA var konfigurationsrelaterade och 31 % av dem var allvarliga. Konfigurationsfel kan ock-så leda till allvarliga konsekvenser. Ett exempel på det är när ett konfigurationsfel orsakade att hela ”.se” domänen var nere i nästan en timme och påverkade ungefär en miljon använ-dare [3]. Ett annat exempel är när en konfigurationsfel påverkade Facebook som gjorde att dess 500 miljoner användare inte hade tillgång till Facebooks hemsida[4].
Utvecklare har ofta mer erfarenhet av vilka biblioteksberoenden och versioner som be-hövs, vilket gör det mer naturligt att det är dem som installerar och konfigurerar RTE:erna. Å
1.1. Syfte
andra sidan har driftpersonalen ofta mer erfarenhet av hur t.ex. operativsystem, servrar och databaser, konfigureras i ett system.
År 2009 myntade Patric Deobris termen DevOps (utvecklare och drifttekniker), som in-om ett par år blev en välanvänd och accepterad term. DevOps innebär att utvecklare (testa-re, programmerare och kvalitetsansvariga) och driftpersonal (de som utvecklar skripts och ”infrastruktur i kod”) ska jobba närmare varandra. DevOps förknippas med att dela idéer, problem, processer, verktyg och mål [5].
Ida Infront använder idag steg-för-steg anvisningar för att sätta upp lokala RTE:er och be-ställningslistor för framtagning och uppsättning av RTE:er på servrar. Denna manuella metod tar lång tid och ökar risken för att något blir fel och att de olika RTE:erna inte blir identiska med varandra eftersom dessa anvisningar kan vara tvetydiga, ouppdaterade samt för spe-cifika och således behöver finjusteras. Till exempel kan olika versioner av programbibliotek resultera i att samma produkt beter sig olika i olika miljöer. Andra fel som felkonfiguration av databasen kan leda till att produkten går väldigt långsamt. Idag uppskattar driftpersonalen att det i genomsnitt tar 2 timmar respektive 4 timmar att sätta upp en RTE med Linux och Windows server.
För att lösa dessa problem vore det önskvärt med ett dynamiskt företagsinternt moln som kan växa och krympa vid behov. Ett sådant moln skulle kunna vara värd för ett antal RTE:er som enkelt kan sättas upp och tas ner av både utvecklare och driftpersonal. De serverbasera-de RTE:erna kan köras båserverbasera-de på Windows och Linux.
De senaste åren har flera verktyg som hanterar och automatiserar virtualisering och kon-figuration tillkommit. Med konkon-figuration av en RTE i detta sammanhang, menas en speci-fikation av vad RTE:n ska innehålla efter installationsprocessen. Samtliga verktyg har sina begränsningar och styrkor för olika typer av domäner så det finns ingen generell modell som passar alla. Därför är det önskvärt med en undersökning av vilka verktyg som finns och en utredning av vilken kombination som fyller företagets behov bäst.
1.1
Syfte
Syftet med arbetet som beskrivs i denna rapport är att ta fram en kombination av verktyg och plattformar som kan automatisera, förenkla, samt minimera konfigurationsfel i processen att sätta upp RTE:er. RTE:ers innehåll ska kunna beskrivas i konfigurationsfiler som konfigura-tionsverktyg kan tolka och installera ifrån. RTE:er ska dynamiskt kunna sättas upp och vid behov tas ner på ett företagsinternt moln för att effektivisera användningen av företagets resurser.
Ett praktiskt exempel av den valda kombinationen ska skapas genom att sätta upp en prototyp. Detta för att avslöja eventuella praktiska problem, evaluera installationsprocessen samt demonstrera lösningen för Ida Infront.
1.2
Problemformulering
Problemet som detta examensarbete ska lösa är att:
• Undersöka vilken kombination av verktyg och plattformar passar bäst för effektivise-ring och felminimeeffektivise-ring vid konfiguration och installation av RTE:er på företagets önsk-värda moln.
• Ta fram en lämplig kombination av verktyg som leder till en automatiserad uppsättning av RTE:er i enlighet med företagets behov.
1.3. Metodsammanfattning
Obligatoriska krav:
1. En ny RTE kan skapas via ett kommandoradsverktyg eller grafiskt gränssnitt.
2. Kommandoradsinterface eller grafiskt användargränssnitt kan användas på Windows, Linux och Mac för att använda lösningen.
3. Antalet RTE:er kan skala upp och ner vid behov. 4. Verktyg och plattformar baseras på öppen källkod.
5. Konfigurationer av RTE:er kan versionshanteras och delas i team. Önskvärda krav:
6. Konfigurationer av RTE:er kan modulariseras för återanvändning.
7. Lösningen ska vara så interoperabel som möjligt. Det vill säga, valda verktyg och platt-formar ska helst inte vara beroende av endast en lösning.
8. Verktyg och plattformar i lösningen ska vara så aktiva som möjligt med ett växande community. Bland annat för att vara framtidssäker.
9. Microsofts Active Directory ska gå att använda i lösningen, då verksamheten i övrigt använder det.
1.3
Metodsammanfattning
För att besvara frågeställningen har först en jämförelsestudie av infrastruktur som en tjänst (eng. Infrastructure as a Service, IaaS) plattformar med hjälp av tillgänglig litteratur genom-förts. Jämförelsestudien fokuserar på aspekter som både anses viktiga för verksamheten och IaaS-plattformar generellt. Val av kombinationen som lösningen består av, bestämdes uti-från jämförelsestudien och teorin som knöts samman med frågeställningen och kraven. En prototyp skapades för att demonstrera och analysera eventuella praktiska problem med lös-ningen. Analysen, som är av den kvalitativa typen, genomfördes genom att installera den valda lösningen i en testmiljö och beskriver problem samt egna subjektiva upplevelser av installationsprocessen och resultatet.
1.4
Avgränsning
Följande begränsningar har vidtagits under arbetet:
1. Arbetet kommer främst att fokusera på uppsättning av RTE:er i en Linuxmiljö på ett företagsinternt moln eftersom att det finns en tidsbegränsning samt att det är som mest problematiskt för företaget. Dock kommer testserverar och produktionsserverar att be-aktas vid val av olika verktyg eftersom tanken är att använda samma system för dem i framtiden.
2. Arbetet kommer till stor del att fokusera på grundpelarna som är molnplattform samt de närmastliggande verktygen.
3. Arbetet kommer heller inte göra någon efterforskning av vilket konfigureringsverktyg som passar bäst till företaget.
1.5. Rapportöversikt
1.5
Rapportöversikt
Följande kapitel innehåller teori, bakgrund och litteraturöversikt, där begrepp som infra-struktur i kod, automatisering av infrainfra-struktur, virtuella miljöer och servrar, hypervisors, containrar och molnplattformar presenteras. Därefter kommer kapitel 3 där arbetets metod beskrivs. I kapitel 4, 5 och 6 finns resultatet av arbetet, där 4 beskriver resultat som fram-kom av litteraturstudien av molnplattformar, 5 valet av molnlösning och 6 hopsättning av prototypen och dess utvärdering. Till sist i kapitel 7 finns diskussion av metod och resultat.
1.6
Språkbruk
Runtime-miljö (RTE) En runtime miljö (Run-Time Environment) innehåller allt som be-hövs för att köra ett program (miljövariabler, biblioteksberoenden, databaser, katalogstruk-tur, etc.) och ingenting annat. I kontext till detta arbete innehåller en RTE bl.a.: Java, databas, applikationsserver, företagsapplikation.
Kommandoradsinterface (CLI) Kommandoradsinterface är ett gränssnitt (terminal) där användare kan exekvera kommandon till ett program.
Grafiskt användarinterface (GUI) Tillåter användaren att interagera med ett program med hjälp av grafiska ikoner, indikatorer etc.
Orkestrering Automatiserad process för arrangering, koordinering och hantering av bl.a. komplexa system och tjänster. Orkestrering innebär ett definierat arbetsflöde som går mot ett större mål (Gör A, sen B och slutligen C).
2
Teori
För att skapa ett företagsintern moln behövs det förståelse av de olika komponenter som ingår, vad som behövs och vad som inte behövs. Detta kapitel presenterar teori om grundläggande
begrepp och metoder inom virtualisering av hårdvara och vilka lager som finns.
2.1
Infrastruktur i kod
Programmerbar infrastruktur och infrastruktur i kod (IaC) är synonymer till varandra och har betydelsen att skriva kod (i vilket programspråk som helst) för att hantera infrastruktur. I det här sammanhanget är infrastruktur varje del av lösningen som inte är mjukvaruappli-kationen i sig, dvs. serverar med konfigurationsfiler, mjukvarupaket som är en del av ope-rativsystemet, crontabar1, applikationsanvändare etc.. Det handlar inte enbart om att skriva skripts utan involverar även att använda testade och välbeprövade metoder inom mjukvaru-utveckling. Till exempel versionshantering (ex. GIT), testning och designmönster.
Installation och underhåll av infrastruktur, har i allmänhet, varit automatiserat sedan länge. Problemet är att det ofta har bestått av handskrivna skripts som är väldigt svåra att läsa och förstå för andra än skaparen. Det kräver också en del erfarenhet och kunskap att skriva dessa skripts eftersom programspråket som används för skripts ofta inte är något som utvecklare använder särskilt ofta. Skript går ibland heller inte att dela mellan olika miljöer då en maskin kan ha beroenden som gör att skriptet inte kan slutföras. Detta kan tillföra en osäkerhet som leder till att installation, underhållning och hantering utförs manuellt istället.
2.2
Automatisering av infrastruktur
Senaste åren har ett stort antal verktyg för att automatiskt hantera infrastruktur utvecklats, vilket det här kapitlet till stor del kommer handla om. Dessa verktyg hjälper bland annat ut-vecklare och driftpersonal att samarbeta genom att skapa en infrastruktur som är mer trans-parent gentemot varandra.
Enligt Hüttermann et al. [5] finns det många brister med det traditionella sättet att han-tera infrastruktur. Vid en uppdatering av en komponent, som kräver ändring i den lokala
2.3. Virtuell miljö
Figur 2.1: Exempel på hur ett versionshanteringsverktyg kan användas.
miljön eller testmiljön, måste varje utvecklare manuellt ändra sin lokala miljö för att anpassa sig efter uppdateringen. Om testmiljöer används måste ändringarna rapporteras till syste-madministratörerna och det är ofta svårt att beskriva ändringarna och chansen för fel och missuppfattningar är stora. Det blir också ofta svårt för nya utvecklare att hoppa in i projek-ten. Detta går att förbättra med moderna verktyg som automatiserar infrastrukturen.
Genom att använda konfigurationshanteringsverktyg (som till exempel Chef2eller Pup-pet3) kan arbetet underlättas, automatiseras och lättare replikeras. Med Chef som exempel, kan konfigurationen skrivas i kod och delas i ett versionshanteringssystem som GIT4, där
kollegor kan titta på, ladda ner, ändra och exekvera för att sätta upp miljön. I figur 2.1 vi-sas ett exempel på hur ett versionshanteringsverktyg kan användas i ett moln/serverhall. Användaren ändrar endast konfigurationstyper på servern och sedan hämtar klienterna sin inställda konfigurationstyp och uppdaterar sig själva.
Boob et al. [6] har jämfört manuell med automatiserad installation och konfiguration. De använde verktyg bestående av bl.a. Vagrant5och Chef för att reducera tiden att sätta upp
en virtualiserad miljö med så lite manuellt arbete som möjligt. De manuella stegen för att sätta upp det var: sätta upp VM med hårdvarukonfigurationer, starta upp operativsystemet i virtuell maskin (VM), installera uppdateringar och beroenden samt ladda ner, konfigurera, kompilera och exekvera applikationer. Den genomsnittliga sammanlagda tiden för att utföra dessa steg för en erfaren användare var 17 minuter vilket kan jämföras med verktygen som automatiserade processen som tog under 4 minuter. Vid manuell uppsättning ökar dessutom chansen för små misstag (som i bästa fall upptäcks) som kan ta ytterligare tid att felsöka. Den automatiserade processen kan dessutom versionshanteras.
2.3
Virtuell miljö
Det första steget för automatisering av infrastruktur i kontext till arbetet är att hitta en lösning för att virtualisera hårdvaran och servrar för att på ett enkelt sätt kunna sätta upp RTE:er. Termen virtuell miljö (eng. virtual environment) betyder tillhandahållande av datorresurser som är oberoende av fysiska maskiner [5]. Virtuella miljöer kan användas för att köra bl.a. virtuella datorer och servrar. Detta innebär en fördel då användare inte behöver bry sig om var eller på vad en programvara kör på, vilket sparar tid.
2.3.1
Varför skapa en virtuell servermiljö?
Sahoo et al. [7] tar upp flera fördelar med att använda virtuella miljöer. Dels flexibiliteten att kunna köra flera operativsystems instanser på en och samma fysiska dator och enkelt kunna flytta över instanser till andra fysiska datorer. Det gör att tillgängligheten ökar då t.ex. en fysisk dator behöver stängas av och underhållas kan de virtuella instanserna temporärt flyttas över
2Chef, https://www.chef.io/ 3Puppet, https://www.puppet.com/ 4GIT, https://git-scm.com/
2.3. Virtuell miljö
till en annan maskin. Enkelheten att lägga till och ta bort instanser ökar skalbarheten. Hård-varuutnyttjandet kommer troligtvis öka då flera instanser körs samtidigt. Isolering av tjänster ökar säkerheten eftersom andra instanser på maskinen inte äventyras ifall en äventyras. Kost-naden för verksamheten minskar troligtvis eftersom en dyrare och mer kraftfull maskin kan ersätta en massa billiga mindre kraftfulla maskiner. Med virtuella miljöer blir lastbalansering lättare då instanser på en högt belastad server kan flyttas över till en mindre belastad server. För att realisera en virtuell miljö så finns en mängd verktyg och plattformar tillgängliga, både av öppen källkod och kommersiella. Arbetet kommer dock fokusera på lösningar av öppen källkod.
2.3.2
Hypervisor
En virtuell maskin (VM) är en mjukvaruimplementation av ett datorsystem som exekverar program likt en fysisk maskin. En VM är en isolerad kopia av en riktig maskin som inte har någon direkt kommunikation med den riktiga hårdvaran. Mjukvaran som kör inuti en VM är låst och begränsad till de resurser och abstraktioner som den virtuella maskinen tillhanda-håller.
En hypervisor är en hanterare för virtuella maskiner (eng. Virtual Machine Manager, VMM), vilket kan vara en mjukvara, firmware eller hårdvara, som delar och hanterar hårdva-ra, så att flera olika miljöer kan exekvera på samma fysiska maskin, isolerade ifrån varandra. Med andra ord, en hypervisor skapar och kör virtuella maskiner (från OS och uppåt). En VMM ligger mellan hårdvaran och OS och ser till att VM:er inte påverkar varandra på ett negativt sätt. Till exempel genom att schemalägga lika stora CPU intervaller mellan olika VM:er.
2.3.3
Container, virtualisering på OS-nivå
Figur 2.2: Hypervisor vs container lösning
En VM kör ett helt operativsystem vilket tar upp en hel del resurser av systemet (t.ex. lagringsutrymme, RAM och processor cykler). Tänkt ett scenario där 100 utvecklare på ett webbutvecklingsföretag använder varsin VM i en serverhall för att testa webbservrar. OS:en i detta scenario kommer med stor sannolikhet behöva majoriteten av hårdvaruresurserna och webbservrarna endast en liten del. I kontrast till en VM som isolerar OS, isolerar istäl-let virtualisering på OS-nivå användarutrymmen på samma OS. I virtualisering på OS-nivå använder gäst-miljöerna ingen hypervisor över huvud taget, utan gästen delar istället sam-ma OS-kärna som värden. Dessa miljöer kallas för containrar och har funnits länge i tekni-ker såsom OpenVZ och VServer samt efterträdaren LXC[8]. I figur 2.2 illustreras skillnaden mellan hypervisor (med VM:er) och container där containerlösningen använder sig av ett
2.3. Virtuell miljö
modernt containerverktyg som heter Docker. En ytterligare skillnad som visas i bilden är att containrar kan dela diskutrymme där exempelvis bibliotek kan delas.
LXC är ett interface i användarrymden för containerfunktioner i Linuxkärnan som tillå-ter att köra flera instanser av isolerade Linux användarutrymmen (eng. user-space), ovanpå endast en Linux kärna. Genom ett API och enkla verktyg, tillåter det användaren att skapa och hantera system- och applikationscontainrar. Målet med LXC är att skapa en miljö som liknar en standardinstallation av Linux men utan att behöva en separat Linux kärna. Detta gör att många fler applikationer kan köras på samma fysiska server jämfört med en VM. LXC använder bl.a. cgroups6(control groups) och chroot7, vilka är Linux kärnfunktioner för pro-cessisolering. I kontrast till en container är en VM enkelt, en isolering bestående av separata OS, istället för isolerade användarutrymmen på samma OS.
Dua et al. [9] har gjort en jämförelse av flera faktorer såsom prestanda, säkerhet, nätverk och lagring mellan virtuella maskiner och containrar:
• Gäst OS. Varje VM kör på en egen virtuell hårdvara och OS-kärnan har ett eget utrymme i minnet medan alla containrar delar OS och kärna.
• Kommunikation. VM använder sig av ethernet enheter medan containrar använder van-liga IPC mekanismer såsom signaler, pipes, sockets, osv..
• Prestanda. VMs har en liten overhead eftersom att maskininstruktioner är översatta från gäst OS till host OS. Containrar har nästan ingen overhead och presterar ungefär lika som värd OS.
• Säkerhet. I en VM beror säkerheten på den hypervisor (VMM) som används. Containrars åtkomstkontroll har säkerhetsbrister.
• Isolering. Delning av exempelvis bibliotek och filer mellan gäst OS och mellan gäst OS och värd OS går inte i en VM. Containrar kan åstadkomma detta med underkataloger. • Uppstartstid. En VM kan ta flera minuter att starta upp jämfört med ett fåtal sekunder
för en container.
• Lagring. Eftersom VM:er behöver egna OS och containrar delar, tar VM mycket mer utrymme.
I tabell 2.1 visas kända programvaror för containrar och hypervisors. Hypervisor Virtualisering på OS-nivå KVM8, VirtualBox9,
VMware10, Xen11, Hyper-V12
LXC13, Docker14, OpenVZ15, VServer16
Tabell 2.1: Programvaror för virtualisering i deras tillhörande kategorier
6cgroups är en funktion i Linuxkärnan som stryper, isolerar och delar ut resurser (minne, CPU, nätverk, disk
I/O).
7chroot är en Unix funktion som begränsar åtkomst till filer i systemet baserat på processer.
8KVM, http://www.linux-kvm.org/
9VirtualBox, https://www.virtualbox.org/ 10VMware, www.vmware.com
11Xen, www.xenproject.org/
12Hyper-V, https://www.microsoft.com/en-us/server-cloud/solutions/virtualization.aspx
13Linux container, https://linuxcontainers.org 14Docker, https://www.docker.com/
15OpenVZ, https://openvz.org 16Linux-VServer, linux-vserver.org/
2.4. Molntjänster
(a) Molntjänst modeller (b) Molntjänststack (c) Exempel på IaaS-virtualisering
Figur 2.3: Molntjänster
2.4
Molntjänster
Molntjänster (eng. cloud computing) tillhandahåller virtuella miljöer för användaren. Defi-nitionen av molntjänster är enligt amerikanska organisationen NIST (National Institute of Standards and Technology), en modell som möjliggör för att överallt och på ett enkelt sätt ha tillgång (via nätverk) till delade konfigurerbara datorresurser (ex. serverar, lagring, tjänster och program) som kan snabbt bli tillhandahållen och tillbakalämnad med minimal interak-tion av leverantören [10]. Med andra ord är en molntjänst en modell för att enkelt tillhanda-hålla en virtuell miljö (container eller VM) till användare.
En enkel tillhandahållen virtuell miljö definieras på olika sätt och delas in i olika abstrak-tionsnivåer. Dessa nivåer visas i figur 2.3a och i figur 2.3b visar vad varje lager abstraherar bort. Nedan följer en beskrivning av de tre huvudsakliga lagren i figuren.
1. Lagret längst ner är själva grunden som kallas Infrastructure as a Service (IaaS), vil-ket levererar infrastruktur som en on-demand tjänst. I IaaS är det användaren som ansvarar för applikationer, lagring, nätverkstjänster (brandvägg), och operativsystem. En IaaS-plattform abstraherar, virtualiserar och tillhandahåller exempelvis hypervisor-hantering, lastbalansering av VM:er och nätverk mellan fysiska maskiner.
I figur 2.3c illustreras grunden i IaaS där ett fåtal fysiska servrar kör många VM:er. En användare kan exempelvis hyra en VM med godtyckligt mycket allokerade resurser av en IaaS-leverantör. Användaren använder då VM:en som en vanlig maskin utan vet-skap om vad den faktiskt kör på eller om VM:en flyttas till en annan fysisk maskin under användning. Ett exempel på en IaaS-leverantör är Amazon Web Services (AWS). 2. Platform as a Service (PaaS) är en utvecklingsplattform som tillåter utvecklaren att ska-pa webbapplikationer utan att behöva köska-pa mjuk- och hårdvara som måste underhållas och konfigureras. Det är en plattform för att leverera mjukvara över nätet och applika-tionerna byggs ofta ihop med fördefinierade block. Oftast är PaaS ett fördefinierat ram-verk med ett begränsat antal programspråk som applikationer måste anpassa sig till. I och med detta hanterar leverantören molntjänsten (operativsystemet, servar, lagring, nätverk, RTE m.m.), medan utvecklaren hanterar och kan fokusera på applikationen. Ett exempel på PaaS är Google Appengine.
3. Software as a Service (SaaS) kan ses som mjukvaran PaaS levererar. De flesta SaaS appli-kationer kan köras direkt av webbläsaren utan att behöva ladda ner något till sin egen dator, dock kan plugins vara nödvändiga. Exempel på SaaS applikationer är Google mail, Google docs och Facebook.
2.4. Molntjänster
OpenStack OpenNebula CloudStack Eucalyptus
Lanseringsår 2010 2008 2010 2008 Skapad av Rackspace Hosting och NASA Ignacio M. Llorente och Rubén S. Montero
Cloud.com Santa Barbara university, Eucalyptus System Company Molnmiljö Privat, Publik, Hybrid Privat, Publik, Hybrid Privat, Publik, Hybrid Privat
Design Tjänststack Integrerad Tjänststack Integrerad
Språk Python C++, Ruby,
Java
Java Java, C
Tabell 2.2: Översikt av plattformarna som kommer att studeras i arbetet
2.4.1
IaaS-plattformar
PaaS (och även SaaS) väljs bort eftersom att modellen abstraherar bort RTE:n, som är tänkt att användas vid testning, vilket medför krav på att det går kontrollera den på ett enkelt sätt. Därför kommer IaaS att vara i fokus resten av rapporten.
För att sätta upp ett IaaS-moln finns det en mängd olika plattformar tillgängliga. Arbetet fokuserar på fyra av de största lösningarna med öppen källkod, OpenStack17, OpenNebu-la18, CloudStack19 och Eucalyptus20. De valdes på grund av att de är allmänt välkända och bland de mest dominerande plattformarna med öppen källkod på marknaden. Plattformarna introduceras kort nedan.
I tabell 2.2 finns en kort översikt och jämförelse av plattformarna. Samtliga plattformar lanserades kort inpå varandra mellan år 2008 och 2010. OpenStack [11] är en sammansätt-ning av projekt med öppen källkod, som företag eller molnleverantörer kan använda för att sätta upp olika typer av IaaS. Dessa projekt kallas även för tjänster och bildar tjänststackar. En tjänststack betyder att tjänster bygger eller kan bygga på varandra likt ett pussel där an-vändaren väljer vilka pusselbitar som ska användas. Likt OpenStack bygger även CloudStack [11], [12] på stackar där tjänsterna exempelvis är molnhanterare, lagringsserver (för volymer, avbildningar och prototyper) och nätverk. OpenNebula [11]–[13] och Eucalyptus har istället en integrerad design där användaren får allt i en enhet. Samtliga plattformar är byggda för privat, publik eller hybrid21molnmiljö, förutom Eucalyptus som endast är byggd för privata miljöer. Alla plattformar är skrivna med unika kombinationer av programspråk där är Java en gemensam nämnare för tre av plattformarna och OpenStack, ensam med att vara skri-vet med Python. Plattformarna har även licenser för öppen källkod som kan användas för kommersiellt bruk, vilket är viktigt i det här sammanhanget.
2.4.2
Tidigare jämförelser av IaaS-plattformar
Det finns ett stort antal studier som jämfört olika IaaS-plattformar. Området har rört sig fort framåt vilket har resulterat att många studier har blivit föråldrade. I tabell 2.3 presenteras käl-la, författare, publiceringsår, vilka plattformar som studerades, syftet och metoden av tidiga-re jämfötidiga-relsestudier. Dessa kommer lägga grund för valet av molnplattform, som ptidiga-resenteras senare i rapporten.
17OpenStack, http://www.openstack.org 18OpenNebula, http://www.opennebula.org/ 19CloudStack, http://cloudstack.apache.org/
20Eucalyptus (Elastic Utility Computing Architecture for Linking Your Programs To Useful Systems), www8.hp.
com/us/en/cloud/helion-eucalyptus.html
2.4. Molntjänster
OpenStack förekom ofta vid framtagningen av jämförelselitteratur i det valda tidsinter-vallet. Totalt valdes det ut 11 studier (som listas i tabell 2.3), där OpenStack förekommer i samtliga, OpenNebula i sju, Eucalyptus i sex och CloudStack i fem. En del av litteraturen innehåller även andra plattformar än de som arbetet valt att fokusera på vilket inte visas här. Fyra av studierna är kvalitativa, fyra kvantitativa och tre innehåller båda metoderna.
De urvalskriterier som användes för att välja källor var att de skulle innehålla jämförel-sestudier utav någon (fler desto bättre) av de fyra största IaaS plattformarna i öppen källkod OpenStack, OpenNebula, CloudStack och Eucalyptus. Då området utvecklas väldigt fort och har gjort det under många år kan litteratur som endast är ett par år gammal vara föråldrad. Därför valdes litteratur som var högst fyra år gammal (2012-2016).
IaaS plattformar
Referensnummer Författare År OpenStack OpenNebula Eucalyptus CloudStack Annan Syfte Metod
[14] S. Yadav 2013 3 3 3 Jämföra olika
molnplattformar för att utvecklare enklare ska kunna välja bland dem.
Kvalitativ, beskrivande ansats [15] A. Pillai 2012 3 3 3 3 Analysera karaktär, arkitektur och användningsområ-den för populära molnplattformar för att enklare kunna välja bland dem. Kvalitativ, beskrivande ansats [16] S. Sharath och A. Basu 2013 3 3 Studera prestanda av molnplattformar för att förstå beteenden och utnyttjandegraden av molntjänster. Kvantitativ prestanda-mätning av disk, CPU, Minne samt tid för att starta VM och registrera avbildning. [17] A. Para-dowski, L. Liu och B. Yuan. 2014 3 3 Demonstrera hur
viktigt det är att utföra prestanda-mätningar på molnplattformar för att förstå en överblick över prestandan innan integrering med produktion. Kvantitativ prestanda-mätning
2.5. Container eller hypervisor i molnet [18] M. Bist, M. Wariya och A. Agarwal 2013 3 3 Jämföra öppna molnplattformar för att hjälpa användare att bestämma det bättre alternativet för deras företag. Kvalitativ [19] O. Sefraoui, M. Aissaoui och M. Eleuldj 2012 3 3 3 3 Jämförelsestudie av vanliga IaaS lösningar och visa möjligheter att bygga ett kraftfullt moln i öppen källkod. Delvis kvalitativ och kvantitativ. [20] J. Mulle-rikkal och Y. Sastri. 2015 3 3 Jämförelsestudie av implementa-tionskomplexitet, stabilitet och prestanda. Kvantitativ prestanda-jämförelse och resten kvalitativt. [21] J. Manjaly och S Jisha. 2013 3 3 3 3 En relativ studie av olika ramverk för molntjänster. Kvalitativ jämförelsestu-die. [13] X. Wen 2012 3 3 Jämförelse av ursprung, arkitektur, hypervisors, säkerhet och andra faktorer. Kvalitativ jämförelse med små kvantitativa delar. [12] A. Vogel 2016 3 3 3 Jämförelseanalys av prestanda samt evaluera flexibilitet och interoperabilitet. Kvantitativ [11] Q. Lei, Y. Jiang och M. Yang 2014 3 3 3 3 Kvantitativ evaluering baserad på ISO definition och NIST referens modell för molntjänster.
Kvantitativ
Tabell 2.3: Vald litteratur för jämförelse av molnplattformar.
2.5
Container eller hypervisor i molnet
De flesta IaaS-plattformar kräver (mer eller mindre) en hypervisor för att kunna köra contain-rar eftersom att de främst är byggda för att köra VM:er. Det bör ändå nämnas att det finns sätt att köra “bare-metal”22exekvering men eftersom att, som tidigare nämnt i sektion 2.3.3, containrar har säkerhetsbrister i nuläget kommer arbetet fokusera på att hitta en lösning som använder hypervisor på IaaS-plattformen.
2.6. Tidigare prestandajämförelser av hypervisors
(a) Endast virtuella maskiner
(b) Virtuella maskiner och
con-tainrar (c) Containrar direkt på värd-OS
Figur 2.4: Exempel på olika IaaS stackar
En container är inte en helt funktionerande dator utan innehåller i princip endast tjänster. Därför körs de ofta på VM:er och detta kräver organisering. Därför finns klusterhanterare som, till exempel, automatiskt placerar ut, skalar och felhanterar containrar, på ett kluster av virtuella maskiner. I figur 2.4 visas olika exempel på IaaS stackar där figur 2.4a visar ett IaaS-moln endast VM:er. Figur 2.4b och 2.4c visar exempel på vart containerhanterare kan ligga i moln-stacken. Containerhanterarna på de olika VM:er kan kommunicera med varandra och en container kan på så vis flyttas mellan VM:er vid en eventuell överbelastning på en VM. Kubernetes23och Docker Swarm24är exempel på sådana verktyg där Kubernetes är den mer
avancerade varianten.
2.6
Tidigare prestandajämförelser av hypervisors
Hwang et al. [22] har gjort prestandatester av hypervisorna Hyper-V, KVM, vSphere och Xen och kom fram till att det inte finns någon som överlag är bättre än någon annan. Olika typer av applikationer drar fördel av olika VMM. Dock kunde testerna visa att vSphere presterade överlag bäst vilket inte förvånade dem eftersom den existerat längst i branschen och har haft den största gruppen av dedikerade utvecklare. Det som även stack ut i testerna var att:
• KVM hade högre minnesrelaterat overhead när många kärnor var aktiva.
• Xen hade hög overhead vid utförande av små diskoperationer och presterade även säm-re i nätverksgenomströmming.
• Hyper-V var mindre effektiv när flera kärnor utförde små sekventiella läsningar och skrivningar.
Shirinbab et al. [23] har gjort en studie av hur KVM, VMware och Xen presterar vid CPU utnyttjande, diskutnyttjande och applikationers responstider. De testade även hur de preste-rade vid live migration genom att mäta stilleståndstiden och den totala tiden för migrationen. Resultatet visade att:
• KVM och VMware presterade bättre vid CPU utnyttjande (nästa samma som målma-skinen) medan Xen hade högst användning.
• KVM och Xen hade samma diskutnyttjande (runt 22000 KB/s) medan VMware hade högst (runt 30000 KB/s).
• Xen hade högst responstid (runt 25 ms.) medan KVM och VMware hade lägst (runt 20 ms.)
• Den totala tiden för migrationen var runt 2 minuter för samtliga. 23Kubernetes, http://kubernetes.io/
2.7. Containerlösningar i OpenStack
• Stilleståndstiden var högst för VMware på hela 3 sekunder medan KVM och Xen var nere 0,7 respektive 0,3 sekunder.
2.7
Containerlösningar i OpenStack
I kapitel 5 väljs IaaS-plattformen OpenStack som en del i lösningen. Därför kommer denna sektion ta upp vilka integrerade containerlösningar som finns i OpenStack.
För närvarande finns huvudsakligen tre sätt att använda köra containrar i OpenStack. Två25av dem är att antingen använda OpenStack tjänsterna Murano eller Magnum som båda
använder sig av Heat. Heat är en tjänst som tillhandahåller en orkestreringsmotor för att hantera en hel livscykel av infrastruktur och applikationer inuti OpenStack. Den kan köra igång flera sammansatta applikationer beskrivet av en textfil mall. Det sista alternativet är att manuellt eller med ett konfigureringsverktyg installera containerorkestreringsverktyg eller skapa containrar på vanliga OpenStack instanser.
Magnum är en ny API tjänst som arbetar tillsammans med Nova. Nova är tjänsten i Open-Stack som hanterar livscykeln av instanser, vilket betyder tillverkning, schemaläggning, och avverkning av VM:er. Magnum använder Heat för att automatiskt skapa instanser som bil-dar en Bay som använbil-dare kan skapa containrar (t.ex. Docker) på. Magnum är till för att tillföra möjligheten att ha ”container som en tjänst” i OpenStack och erbjuder möjligheten att välja mellan olika container orkestreringsverktyg (t.ex. Kubernetes eller Docker Swarm). Med Magnum kan containrar använda samma autentisering (användarnamn, lösenord etc.) som vanliga instanser i OpenStack. Magnum kan även integreras i OpenStacks webb-GUI för enklare hantering.
Murano är en applikationskatalog som kan skapa Kubernetes-baserade applikationer som körs i containrar. Utvecklare kan skapa containerapplikationer som användare enkelt kan an-vända, utan att användaren vet om att det faktiskt är en container. Murano passar sig därför bättre för utvecklare som skapar applikationer för användare och Magnum för utvecklare som skriver applikationer för sig själva.
2.7.1
Docker - containermetod i IaaS
Efterforskning av containerlösningar indikerade att Docker är lösningen som står mest i cent-rum idag efter LXC. Docker är ett projekt i öppen källkod för att automatisera processen att placera ut applikationer i containrar genom att abstrahera och automatisera virtualisering på operativsystemsnivå. Docker containrar är designade för enskilda applikationer och appli-kationscontainrar är uppbyggda av lager för att sedan kunna koppla ihop dem till en större applikation.
Docker har en motor som omfamnar applikationer med ett självständigt filsystem (istället för att använda samma filsystem som userspace) för att skapa intrycket att endast en process körs. Docker använder LXC för att kommunicera med Linuxkärnan men har ett eget bibliotek för containrar (libcontainer).
Docker använder sig av ett Makefile-liknande skript som kallas Dockerfile, för att exakt definiera vad som ska finnas i avbildningen vilket har många fördelar [24]:
• Maskinavbildningar är väldigt stora, ofta flera gigabytes men en Dockerfil är endast en textfil som enkelt kan sparas och delas.
• Dockerfilen gör versionshantering enklare.
• Istället för att behöva lägga ner en massa tid på att ta reda på och skriva ner alla bero-enden i slutet på ett projekt så skrivs dom ner allt eftersom.
25Magnum vs Murano: An OpenStack container strategy,
2.7. Containerlösningar i OpenStack
• Dockerfilen innehåller alla beroenden ner till OS nivån vilket gör det högst troligt att byggen blir exakt samma på olika maskiner.
• Det är möjligt att lägga in tester och kontroller när miljöer installeras. • Ändringar av avbildningen genomförs att ändra i Dockerfilen. Docker har dock också begränsningar [24]:
• Som tidigare nämnt har containrar och därmed Docker inte stöd för full virtualisering utan förlitar sig på underliggande Linuxkärna som tillhandahålls av värden vilket bl.a. kan äventyra säkerheten.
• Dockerfiler är osignerade och kan därmed äventyra säkerheten. • Kan endast användas på Linuxkärna.
• Begränsad till 64 bitars värdar vilket gör det omöjligt att köra Docker på gammal hård-vara.
Dockerfilen är en unik funktion som löser konfigurationsproblem. Därför är Docker ett extra intressant verktyg för arbetets molnlösning då det löser konfigurationskraven (i sektion 1.2).
3
Metod
I det här kapitlet beskrivs hur frågeställningen ska besvaras. Först beskrivs metoderna och vilka parametrar som valet av lösning kommer baseras på. Därefter beskrivs det hur lösningen
tas fram. Till sist, hur prototypen ska utformas.
En efterforskning av metoder som skulle kunna vara användbara för att ta fram en modell som passar verksamhetens behov genomfördes. Efterforskningen gick till genom att söka ef-ter tidigare studier och artiklar som handlar om metoder för framtagning av molnplattformar och verktyg för enskilda verksamheter. Ingen lämplig metod hittades och slutsatsen av studi-en var att jämförelser och urval måste skräddarsys till varje studi-enskilt fall vilket är svårt göra studi-en generell metod för då olika verksamheter skiljer så pass mycket och lösningsalternativen är väldigt många. En annan orsak till att ingen lämplig metod kan hittas, kan vara att området är nytt och går väldigt fort framåt. Nya plattformar, tekniker och funktioner lanseras mycket frekvent och forskning blir snabbt gammal.
För att skapa ett företagsintern IaaS-moln finns det en mängd olika plattformar tillgäng-liga. För att delvis kunna svara på frågeställningen i sektion 1.2 ska en jämförelsestudie av olika IaaS-plattformar genomföras. Eftersom att det inte fanns tid att testa och evaluera alla plattformar under arbetet har tidigare litteraturstudier använts. I sektion 2.4.2 presenterades jämförelselitteratur av IaaS-plattformar som kommer användas i denna evaluering.
Då arbetet strävar efter en molnlösning för att göra det enkelt för utvecklare att sätta upp en RTE snabbt och smidigt, valdes strategin att välja en så hög abstraktionsnivå som möjligt, utan att skala bort något som är nödvändigt utifrån kravbilden. Som tidigare nämnt så väljs PaaS (och även SaaS) bort eftersom att modellen abstraherar bort RTE:n, som är tänkt att användas vid testning, vilket medför krav på att det går kontrollera den på ett enkelt sätt.
IaaS-plattformen kommer med hög sannolikhet inte vara tillräckligt för att uppfylla samt-liga krav. Därför kommer den valda plattformen kompletteras med andra verktyg i den mån som behövs.
3.1
Jämförelsestudie av IaaS plattformar med hjälp av litteratur
Jämförelsestudien fokuserar på kriterier från frågeställningen och kravspecifikationen (sek-tion 1.2). Dock kommer inte alla kraven att tas med då en IaaS-plattform inte är menat att lösa
3.1. Jämförelsestudie av IaaS plattformar med hjälp av litteratur
alla, t.ex. konfiguration av RTE:er. För att lösa alla krav kommer IaaS-plattformen att behöva kompletteras med andra verktyg.
Ytterligare kriterier som anses viktiga för en IaaS-plattform i kontext till verksamheten har tagits fram för att kunna urskilja dem bättre och göra valet enklare.
3.1.1
Tillvägagångssätt
Litteraturstudien av molnplattformarna OpenStack, OpenNebula, CloudStack och Eucalyp-tus utvärderas dels, genom att fokusera på aspekter som direkt anses viktiga för verksam-heten, vilka härstammar från kraven. Dessa är beräkningsfunktionalitet för att överhuvud kunna köra RTE:er, funktionalitet för att skala, användarvänligt användargränssnitt som kan användas från operativsystemen Linux, Windows och Mac samt plattformens aktivitet. And-ra aspekter som indirekt är viktiga utvärdeAnd-ras också. Till exempel behöver inte plattformen kunna skala till tusentals noder eller ha bäst prestanda eftersom verksamheten inte har behov av det. Men om en plattform har de egenskaperna, är det ett tecken på att den är välutveck-lad, mogen, konkurrenskraftig samt har större potential att vara framtidssäker.
De kategorierna som har valts ut för att undersöka är nyckelfunktioner, interoperabilitet, skalbarhet, grafiskt gränssnitt, användarvänlighet, autentisering. För att kunna mäta katego-rierna och jämföra dem mellan plattformarna kommer varje kategori vara värd som mest fem poäng. Saknas det en egenskap definierat i kategorikriterierna, dras poäng av. Kategorierna beskrivs nedan och poängsystemet beskrivs i tabell 3.1.
1. Nyckelfunktioner. Nyckelfunktioner är de grundläggande funktionerna för beräkning (VM:er, snapshots och maskinavbildningar), nätverk (IP adresser, VPN, VLAN, lastba-lansering) och lagring (blocklagring, objektlagring).
2. Interoperabilitet. Interoperabilitet kommer mätas i hur varje plattform har stöd för con-tainrar samt hur många hypervisors och Linuxdistributioner stöds.
Ida Infront använder idag hypervisorn VMware (vSphere) för andra syften än RTE:er men har inte bestämt sig vilken hypervisor som kommer att användas i framtiden. Där-för är det viktigt att plattformen som väljs har så många alternativ som möjligt Där-för att verksamheten kan eventuellt byta till en annan i framtiden.
Containrar är väldigt intressanta med de fördelar de tillför och kommer därför att pla-ceras under denna kategori.
3. Skalbarhet. Antalet RTE:er kommer inte vara statiskt, därmed krävs det att plattfor-men kan skala med antalet RTE:er som behövs för tillfället. Därför kommer det också undersökas om plattformarna har funktionalitet för att skala och hur bra de skalar. 4. Autentisering. Då företaget idag använder sig av Microsoft Active Directory (AD) för
autentisering är det ett stort plus om plattformen har det. I övrigt så kommer molnet vara relativt isolerat från omvärlden och därför har inte säkerheten särskilt hög priori-tet.
5. Användarvänlighet. En viktig del i arbetet är att förenkla och effektivisera processen att sätta upp en RTE. Därför är det mycket bra om plattformen har ett grafisk gränssnitt för att användare bland annat enkelt ska komma igång.
Dokumentation, installationskomplexitet och öppenhet kommer även undersökas i stu-dien. Dokumentation och installationskomplexitet konvergerar till viss del. Bra doku-mentation är viktigt för att korrekt kunna installera och underhålla dessa komplexa plattformar. Ännu viktigare är det att dokumentationen är välgjord och uppdaterad om installationskomplexiteten är stor.
Det är också väldigt bra om så mycket av projektet är av öppen källkod och gratis då det är med i kravspecifikationen.
3.1. Jämförelsestudie av IaaS plattformar med hjälp av litteratur
6. Prestanda. Prestandan är inte så viktigt då inga tunga arbetsuppgifter är tänkt att köras på molnet. Men som tidigare nämnts kan prestandan vara ett mått på hur väl utvecklad en plattform är, vilket tillför massa andra fördelar.
7. Aktivitet. Utöver förstudien kommer aktiviteten och populariteten studeras genom att samla in och analysera data. Datan kommer att bestå av intresset på Google Trender1
samt projektstatistik bestående av bidragsgivare2och antal bidrag över tid.
Kategori Krav Poängvillkor Poäng
Nyckelfunktioner Beräkningsfunktionerna VM:er, snapshots och maskinavbildningar 0 1-2 Alla 0 1 2 Nätverk (IP adresser, VPN,
VLAN, lastbalansering) - 2 Lagring (blocklagring, objektlagring) - 1 Interoperabilitet Containerstöd - 1 Antal hypervisors 0-1 2-3 >3 0 1 2 Antal Linuxdistributioner 0-2 3-4 >4 0 1 2
Skalbarhet Kan skala - 3
Skalbarhet i jämförelse med de andra plattformarna Sämst Medel Bäst 0 1 2 Autentisering Har Microsoft Active Directory
(AD)
- 5
Användarvänlighet
Användargränssnitt som funkar på Windows, Mac och Linux
Inget Endast CLI GUI 0 1 2 Installationskomplexitet relativt
till andra plattformar
Dålig Bra
0 1 Dokumentation relativt till andra
plattformar
- 2
Öppenhet av källkod Inget/delvis Helt
0 1 Prestanda Prestanda relativt till andra
plattformar
- 5
Aktivitet
Intresse relativt till andra plattformar
- 3
Projektaktivitet relativt till andra plattformar
- 2
Tabell 3.1: Poängsystem för evaluering utav de valda molnplattformarna
Valet av molnlösningen kommer att bestämmas utifrån jämförelsestudien, teorin, fråge-ställningen och kraven.
1Google Trender är baserad på Google sökningar, visar frekvensen av söktermer relativt till totala sökvolymen,
https://www.google.com/trends/
3.2. Prototyp
3.2
Prototyp
En prototyp kommer skapas för att demonstrera lösningen. Syftet med prototypen är att ska-pa ett moln i en miljö som är så likt en produktionsmiljö som möjligt för att synliggöra even-tuella praktiska problem, säkerställa att kraven även uppfylls i praktiken samt demonstrera hur lösningen skulle kunna se ut. Eftersom processen att sätta upp ett moln är komplex, kommer även installationsprocessen utvärderas kvalitativt. Utvärderingsgrunden kommer därför bestå av kraven från sektion 1.2 samt en kvalitativ bedömning av dokumentation och installationsprocessen.
Produktionsmiljön består av ett företagsinternt nät och en server med 16 kärnor, 80 GB RAM och 1 TB hårddisk som använder virtualiseringsplattformen VMware vSphere för att skapa VM:er. Nätverket har ca 2000 adresser varv 254 stycken kommer vara allokerat till prototypen.
Efter valet av molnlösning (kapitel 5) samt skapandet av prototypen (kapitel 6) kommer frågeställningen i kapitel 1.2 att besvaras.
Ett IaaS-moln kräver mycket konfiguration och många installationsmoment och för att prototypen ska bli flexibel, portabel och replikerbar kommer versionshanteringsverktyget GIT och konfigurationshanteraren Chef användas. Med dessa verktyg kan hela installations-processen versionshanteras, automatiseras och användas för att identiskt installera prototy-pen på liknade system. Dessa verktyg valdes främst för att de kändes bekanta.
Chefs kokböcker, som definierar ett scenario och innehåller allt som behövs för det scena-riot (t.ex. resursdefinition, attribut, filer, mjukvaruinstallation etc.), kommer att användas för modularisering av arbetet i så hög grad som möjligt för att kunna ta ur och in olika verktyg och tjänster i prototypen samt att förbättra läsbarheten. Chef använder mallar för konfigu-rationsfiler där variabler kan användas. Variablerna definieras i en fil med projektets miljö-beskrivning, vilket gör att ändringar av t.ex. IP-adresser, nätverk, värdnamn, lösenord bara behöver ändras på ett ställe. Mallarna kopieras till rätt katalog genom enkla funktioner. Flera noder som använder samma installationsförfarande kan dela kod. Om användaren är något familjär med Bash är det enkelt att lägga till kontroller innan diverse kommandon exekveras utan att behöva if-satser. Med denna process blir det enklare att testa och föra in ytterligare kontroller och felhantering.
Konfiguration och installationsprocesser från bl.a. dokumentation, kommer föras in i Chef-skript. Chef-projektet kommer sedan att klonas ner och exekveras på maskinen som ska konfigureras. Chef projektet kommer exekveras av chef-solo, som är en självständig agent som inte kräver någon server.
3.2.1
Testmiljö
Eftersom IaaS-plattformar är komplexa system bäddar det för en hel del fel (konfigurations-misstag, buggar m.m.) och därför beslutades det att inte direkt använda det interna nätet. Det är mycket som händer i ett moln och risken att det kunde störa det interna nätet, speciellt i testfasen och upplärningen, kunde inte uteslutas. Det är också lättare och smidigare att testa miljön på en lokal dator än att behöva fjärrstyra. Därför kommer en testmiljö sättas upp be-stående av en Intel i5 processor (4 kärnor), 16 GB RAM och 120 GB Solid State Drive (SSD), Ubuntu samt VirtualBox med två Ubuntu Trusty noder. VirtualBox har support för NAT nät-verk vilket gör att ett nätnät-verk som är mycket likt det företagsinterna nätet kan skapas.
4
Förstudie av molnplattformar
I sektion 2.4.2 presenterades litteraturen för förstudien av molnplattformar och i sektion 3.1 förklarades metoden. Detta kapitel består av de resultat som framkom utav litteraturen och metoden som går ut på att jämföra plattformarna utifrån valda aspekter och ett poängsystem.
Resultaten sammanfattas i slutet av kapitlet.
4.1
Nyckelfunktioner
I sektion 3.1.1 tillkännagavs kategorierna för detta kapitels rubriker och i tabell 3.1 beskrevs poängsystemet.
Det är inga tvivel om att samtliga plattformarna OpenNebula, Eucalyptus, CloudStack och OpenStack inte skulle ha alla grundläggande beräkningsfunktioner såsom VM:er, snap-shot, och maskinavbildningar. Däremot saknade OpenNebula många nätverks- och lagrings-funktionalitet, såsom IP adresser, VPN, VLAN, lastbalansering, objektlagring, blocklagring m.m. [11], [19]. Detta kan dock åstadkommas med extern mjukvara.
4.2
Interoperabilitet
Samtliga plattformar har stöd för hypervisorna Xen, KVM och VMware [11], [12], [19], [21]. Utöver detta är det OpenStack och CloudStack som även har stöd för fler såsom Hyper-V, QEMU och VirtualBox.
Eucalyptus är den enda som har support för Windows och Linux [12], [14], [25]. Alla andra har endast stöd för Linux och det finns olika beskrivningar om vilka distributioner de har stöd för [11], [12], [14], [21], [25], vilket kan bero på att olika versioner studerades i de olika studierna. Vogel et al. [12] menar att OpenNebula, CloudStack och OpenStack har stöd för Ubuntu och Debian. OpenNebula har utöver det stöd för RedHat, SUSE och CentOS. OpenStack, RHEL, CentOS, Fedora och SUSE. CloudStack, RHEL och CentOS. Eucalyptus har endast stöd för ett OS [11].
OpenStack är den plattformen som haft stöd för Linux Containrar (LXC) sedan 2013 [14], [18], [21]. OpenNebula och CloudStack har väldigt nyligen fått stöd för LXC[12] och baserat
4.3. Skalbarhet
på litteraturen, verkar inte Eucalyptus ha något stöd alls, då ingen information om det kunde hittas.
4.3
Skalbarhet
Alla plattformar har funktionalitet för skalning [11], [19], [21]. Sefraoui et al. [19] hävdar att CloudStack och OpenStack skalar till flest antal instanser, jämfört Eucalyptus och OpenNe-bula. Författarna menar att OpenStack används utav företag över hela världen och skalar upp till 1 miljon fysiska maskiner och upp till 60 miljoner virtuella. Detta inkluderar även CloudStack, som är designat för att skala. De påstår även att Eucalyptus skalar minst ef-ter OpenNebula i jämförelse till den massiva skalningen de två förstnämnda har. De skriver även att Eucalyptus används av Amazon EC2 men inte hur skalbart det är.
Det påstås även att OpenStack är unik med att kunna hantera massiv skalning i jämförelse med bl.a. OpenNebula, utan mer motivering än att många av OpenStacks komponenter inte har någon begränsning till hur mycket de kan skala. [21].
4.4
Autentisering
Ingen information kunde hittas i litteraturen om någon av plattformarna stödjer Active Directory (AD). Däremot har alla plattformar stöd för autentisering i andra former.
4.5
Användarvänlighet
OpenStack, CloudStack och OpenNebula har alla egna interna grafiska gränssnitt [12]. Euca-lyptus saknar grafiskt gränssnitt [11].
OpenStack och CloudStack har bäst dokumentation medan Eucalyptus och OpenNebula har sämre [19]. Det kan vara orsaken till att CloudStack och OpenStack har enklare instal-lationsprocess [19]. Mullerikkal et al. [20] jämförde även de instalinstal-lationsprocessen mellan OpenStack och CloudStack. Resultatet är att CloudStack har mindre installationskomplexi-tet. Sefraoui et al. [19] har även undersökt hur öppna plattformarna är vilket visade att vissa moduler i Eucalyptus är väldigt stängda medan OpenStack, CloudStack och OpenNebula är helt öppna. Detta kan vara relaterat till Pillai et al.[15], som påstår att Eucalyptus är mindre modifierbar jämfört med OpenNebula och OpenStack där nästan allt går att modifiera.
Överlag är det väldig få som undersökt dokumentation, installationssvårighet och öppen-het.
4.6
Prestanda
Fyra av artiklarna jämförde prestandan mellan olika plattformar [12], [16], [17], [20]. Para-dowski et al. [17] och Mullerikkal el al. [20] jämför OpenStack och CloudStack med olika metoder och kommer fram till liknande resultat. Paradowski et al. mäter tiden att distribuera och ta bort instanser med olika resursåtstramningar. Resultatet visar att OpenStack överträf-fade CloudStack i samtliga tester. Skillnaderna är relativt små, mellan 1 och 10 % beroende på test, men det går tydligt att se skillnaderna. En intressant aspekt var att båda plattformarna har väldigt liknande arkitektur men skrivna i olika språk, vilket författarna hävdar kunna vara orsaken till skillnaderna i prestanda.
Mullerikkal el al. gjorde prestanda tester med Bonnie++1och UnixBench2. Bonnie++ är ett verktyg för att utföra prestandatester på filsystem och UnixBench ett verktyg för att utföra och tillhandahålla en grundläggande prestandaindikator. De kommer fram till att OpenStack är mer mogen och stabil. OpenStack visade ha bättre system prestanda i nästan alla tester.
1Bonnie++, http://www.coker.com.au/bonnie++/ 2UnixBench, https://github.com/kdlucas/byte-unixbench
4.7. Aktivitet och Community 1 10 20 30 40 50 0 200 400 600 800 1,000 1,200 Vecka Antal commiter OpenStack OpenNebula CloudStack Eucalyptus
(a) Commit aktivitet för OpenStack, CloudStack, Eucalyptus och OpenNebula 52 veckor framåt från Maj 2015.[26]–[29] 2009-01-01 2010-05-16 2011-09-28 2013-02-09 2014-06-24 2015-11-06 0 20 40 Bidragsgivar e OpenStack OpenNebula CloudStack Eucalyptus
(b) Antal bidragsgivare som bidragit per vecka.[26]–[29] 2008 2009 2010 2011 2012 2013 2014 2015 20160 20 40 60 80 100 År Intr esse CloudStack OpenStack OpenNebula Eucalyptus
(c) Trender i Google Insights för nyckelorden OpenStack, CloudStack, Eucalyptus och OpenNebula under kategorin: Datorer och elektronik-> Mjukvara".[30]
Figur 4.1: Community statistik för IaaS-plattformarna
Sharath et al. [16] jämför prestandan (bl.a. CPU, minne, disk) mellan OpenStack och Euca-lyptus . Resultatet visar att OpenStack är överlag bättre än EucaEuca-lyptus. Dock konstaterades det att Eucalyptus är mer lämpad för på minnesintensiva applikationer och OpenStack CPU-intensiva.
Den sista studien utav Vogel et al. [12] undersöker, analyserar och utför prestanda tester på OpenStack, CloudStack och OpenNebula. Prestandatesterna genomfördes genom intensi-va arbetsbelastningar (på CPU, minne, lagring och nätverk) samt med hjälp av vetenskapliga applikationer. Plattformarna presterar generellt lika i studien, men en del tester visar vis-sa skillnader. Bland annat vivis-sar det sig att OpenNebula har dålig hårddiskgenomströmming och att OpenStack presterar lite bättre än OpenNebula och CloudStack på minnesoperationer då OpenStack var mer stabil (mindre variationer) i samtliga tester.
4.7
Aktivitet och Community
Eftersom plattformarna är utav öppen källkod är det intressegruppen som utför teknisk sup-port, underhållning och utveckling av plattformarna. Dock erbjuder vissa företag tredjeparts-tjänster för teknisk support. Intressegruppen för öppna källor består av användare, utveck-lare, företag, med mera och det är viktigt att aktiviteten inte sjunker utan helst växer för att produkten ska ligga i framkant på marknaden.
Oktober 2012 samlade Lei et al. [11] in statistik från epost-listor och officiella forum under ett år. Resultatet av undersökningen visade att Eucalyptus och OpenNebula låg på 300-500 meddeladen i månaden under hela perioden medan OpenStack och CloudStack gick från 1500-2000 till 3500-4000 meddelanden per månad. Vid undersökningen av aktiva användare hade CloudStack (200-300), Eucalyptus (ca 100) och OpenNebula (ca 100) ungefär samma
4.8. Sammanfattning
antal användare under hela perioden medan OpenStack växte från 300-400 till runt 800-900 aktiva användare.
För att undersöka detta ytterligare med nyare data har data från Google trends och ak-tivitet från GitHub används. I figur 4.1a visas statistik av commitakak-tivitet på de olika platt-formarna. Datan är tagen ett år bakåt från April 2016 och det framgår tydligt att OpenStack har mycket mer aktivitet än de andra tre som ligger ungefär runt samma intervall. I figur 4.1b visas statistik på hur många olika bidragsgivare per vecka som bidragit till respektive projekt. En fallande trend för CloudStack som startar ungefär vid den stigande trenden för OpenStack kan observeras. I figur 4.1c visas sökintresset från Google trends (i kategorin DD-atorer och elektronik-> Mjukvara") som är en mätning av antal sökningar i förhållandet till den högsta punkten. I alla tre figurer kan man se en överlägsenhet av OpenStack.
4.8
Sammanfattning
IaaS plattformar
Eucalyptus OpenNebula CloudStack OpenStack
Nyckelfunktioner +++++ +++ +++++ +++++ Interoperabilitet ++ +++ ++++ +++++ Skalbarhet ++ +++ ++++ +++++ Autentisering - - - -Användarvänlighet ++ ++++ +++++ +++++ Prestanda ++++ ++++ ++++ +++++ Aktivitet ++ ++ +++ +++++
Tabell 4.1: Summering av litteraturstudie av molnplattformar i kontext till arbetet. Det framgick sällan i den valda litteraturer, vilken plattform de rekommenderade ef-tersom att olika specifikationer passar olika ändamål. Många av artiklarna är upplagda på ett sådant sätt, att läsaren är den som ska bedöma vilken plattform som passar bäst. Dock var det ändå överlag lite som indikerade på att OpenStack inte skulle kunna vara den bästa platt-formen för de många behov. Eucalyptus är plattplatt-formen som visade sig vara minst lämpad för företaget, framförallt för att den saknar stöd för LXC och grafiskt gränssnitt men också för att den saknar mest funktionalitet och inte är helt öppen.
Två kvantitativa studier som analyserade samtliga valda plattformar, konstaterade att OpenStack, generellt är bäst i de studerade kategorierna[11], [19]. En annan påstod att Open-Stack är den mer attraktiva plattformen jämfört med CloudOpen-Stack på grund av det stora com-munity och antalet företags initiativ med OpenStack för att sätta upp privata moln i organi-sationen [20].
I tabell 4.1 visas en sammanställning av litteraturstudien. Graderingen är subjektiv och relativ till varandra där fem plustecken är högst och ett lägst. Tabellen visar att OpenStack har bäst resultat i evalueringen följt av CloudStack, OpenNebula och Eucalyptus i fallande ordning.
5
Val av molnlösning
Det här kapitlet kommer knyta an förstudie och teori till den ursprungliga målsättningen och kraven för att ta fram en lösning som uppfyller de ställda kraven.
5.1
Molnplattform
Eucalyptus är den plattformen som överlag presterade sämst och OpenStack bäst. Eucalyp-tus är den enda plattformen som inte levde upp till alla kraven då stöd för grafiskt gräns-snitt och containrar saknades. OpenStack har haft stöd för containrar under längre tid än de övriga vilket kan tyda på att plattformen är mest mogen för användning av containrar i produktion. OpenStack uppfyller sammanfattningsvis alltså kraven att genom tillhandahål-la ett ptillhandahål-lattformsoberoende användargränssnitt för att skapa RTE:er från en diskavbildning. RTE:erna kan enkelt skala efter behov, givet att resurser finns tillgängliga. Kravet för öppen källkod uppfylls.
CloudStack var plattformen som fick högst snittbetyg efter OpenStack och gav vika i skal-barhet, prestanda och projektaktivitet. OpenStacks projektaktivitet visade sig vara väldigt hög jämfört med de andra plattformarna. Detta kan dock bero på att OpenStack är relativt ny och därför har mer behov av uppdateringar. Två av de valfria kraven är att lösningen skall vara interoperabel och aktiv med ett stort community vilket OpenStack bevisats uppfylla
Resultatet av förstudien pekar på att OpenStack är den plattform som verksamheten bör satsa på. Därför kommer OpenStack att väljas för prototypen.
5.2
Hypervisor
OpenStack och de flesta andra IaaS-plattformar behöver en hypervisor som tar hand om in-stanser. I sektion 2.6 tas tidigare jämförelser av hypervisors upp. Där visades det att hypervi-sorna har mycket snarlik prestanda. Därför valdes KVM som hypervisor eftersom att det är standard i OpenStack.
Det är möjligt att ett annat val är bättre för just de RTE:er som arbetet innefattar. Till exempel bör man kanske välja VMware om många databaser kommer köras på molnet, då
5.3. Containerlösning
VMware har högst diskutnyttjande. Dock ingår inte någon sådan utvärdering inom ramen av arbetet.
5.3
Containerlösning
En RTE kan antingen ligga i en VM eller container inuti en VM. I sektion 2.3.3 togs fördelar och nackdelar upp med att använda containrar istället för endast hypervisors på det tradi-tionella viset. RTE:erna som ska köras på molnet är kortlivade, enbart är till för utveckling samt befinner sig på det företagsinterna nätet är säkerheten inte kritiskt. Containrar är därför idealt att använda i det här fallet.
5.3.1
Containerintegration med OpenStack
I sektion 2.7 diskuterades olika OpenStack lösningar. Magnum visade sig vara lösningen som vi är ute efter då Murano är mer tillför användare och inte utvecklare.
Magnum har dock endast funnits i drygt ett år i skrivande stund, vilket kan medföra att det existerar en del buggar i tjänsten. Ett annat alternativ är att installera ett containerorkest-reringsverktyg ovanpå OpenStack utan samverkan. Nackdelen med det alternativet är att det inte går att använda och integrera OpenStacks autentiseringstjänst Keystone, webb-GUI och andra lösningar med containerlösningen. Detta gör att ytterligare en plattform måste under-hållas istället för att ha allt på ett ställe. Magnum har klivit ur betastadiet och en stabil version verkar existera. Därför beslutades det att Magnum ändå kan vara det bästa valet och kommer implementeras i prototypen för ytterligare analys.
5.3.2
Virtualisering på OS-nivå
Det finns flera verktyg att välja mellan för virtualisering på OS-nivå. Intrycket pekar dock på att Docker är det mest kompletta alternativet och verktyget som det fokuseras mest på. Con-tainerklusterhanterare som Kubernetes arbetar som standard med Docker-containrar. Open-Stack har i sin tur stöd för Kubernetes och Docker Swarm. Varför Docker har så stort infly-tande beror förmodligen på att de samarbetar med många av de stora jättarna (t.ex. Google och Red Hat). Docker använder som tidigare nämnts LXC och har bl.a. gjort det enklare och användarvänligare för användare.
Docker har även fördelen med att användare specificerar exakt vad som ska befinna sig i containern genom Dockerfilen. I kravspecifikationen i sektion 1.2, ska konfiguration enkelt kunna delas i team, kunna modulariseras för återanvändning och versionshanteras vilket Docker uppfyller. Docker verkar därför vara det bästa valet av container för verksamheten.
5.4
Konfigureringsverktyg och reproducering
Docker uppfyller kraven som konfigureringsverktyg är till för att lösa och därför anses in-te något konfigureringsverktyg behövas. Dock är Docker väldigt funktionsfattigt och enkelt jämfört med ett dedikerat konfigureringsverktyg (såsom Chef eller Puppet). Dedikerade kon-figureringsverktyg kan användas i Docker om så behövs, men kommer inte att undersökas ytterligare i detta arbete.
5.5
Summering
Lösningen som valts illustreras i figur 5.1 och består alltså av OpenStack som underliggande IaaS-plattform som antalet fysiska serverar enkelt kan skalas upp och ner. Valet av hypervisor är likgiltigt för tillfället och lämnas för en framtida undersökning. Därför kommer den hyper-visorn som är inställt som default i OpenStack användas. OpenStacks tjänst Magnum valdes
