Monitorering av OpenStack ved UiB Monitoring OpenStack at UiB

Transkript

1 Kandidatnummer: h Monitorering av OpenStack ved UiB Monitoring OpenStack at UiB DAT190 Bacheloroppgave Institutt for data- og realfag Avdeling for ingeniør- og økonomifag Antall ord Kristian Ådlandsvik Skurtveit Jeg bekrefter at arbeidet er selvstendig utarbeidet, og at referanser/kildehenvisninger til alle kilder som er brukt i arbeidet er oppgitt, jfr. Forskrift om studier og eksamen ved Høgskolen i Bergen, 6-1

2 Avdeling for ingeniør- og økonomifag Institutt for data- og realfag TITTELSIDE FOR HOVEDPROSJEKT Rapportens tittel: Monitorering av OpenStack ved Universitetet i Bergen Forfatter(e): Kristian Ådlandsvik Skurtveit Studieretning: Drift av datasystemer Kontaktperson ved studieretning: Bjarte Kileng Merknader: Oppdragsgiver: IT-avdelingen, Universitetet i Bergen Oppdragsgivers kontaktperson: Tor Lædre Dato: Antall sider u/vedlegg: 37 Antall sider vedlegg: 8 Antall disketter/cd-er: 0 Gradering: Ingen Oppdragsgivers referanse: Telefon: Sammendrag: Denne bacheloroppgaven går ut på å undersøke ulike monitoreringsløsninger og anbefale verktøy til overvåking av OpenStack-rammeverket i universitets- og høgskolesektorens skyprosjekt. Med utgangspunkt i krav fra oppdragsgiver er resultatet av oppgaven en anbefaling av et monitoreringsoppsett bestående av flere ulike verktøy som har blitt spesialtilpasset til å overvåke OpenStack. Oppsettet har blitt installert i et testmiljø og overlevert til skyprosjektet. Stikkord: Monitorering OpenStack Universitetet i Bergen Høgskolen i Bergen, Avdeling for ingeniør- og økonomifag Postadresse: Postboks 7030, 5020 BERGEN Besøksadresse: Inndalsveien 28, Bergen Tlf Fax E-post: post@hib.no Hjemmeside: 2

3 Forord Jeg vil først og fremst takke skyprosjektet hos UiB som har latt meg delta i prosjektet både gjennom utplasseringsfag og gjennom mitt arbeid med bacheloroppgaven. Det har vært en svært kjekk og lærerik prosess. Dere har gitt meg en unik mulighet til å utvikle min kunnskap og jeg har lært mye nytt om kodedefinert infrastruktur og om monitoreringsverktøy. Jeg vil spesielt takke Tor Lædre, overingeniør ved IT-avdelingen hos UiB. I tillegg til korrekturlesing og utlån av eget kontor, har han gitt mange gode tips og råd underveis med oppgaven. Jeg ønsker videre å takke min veileder Bjarte Kileng som har kommentert og gitt konstruktive tilbakemeldinger på min oppgave. En stor takk rettes til Jostein Smørås som har satt av mange timer til korrekturlesing av oppgaven. Jeg har satt stor pris på artige stunder og god hjelp. Like stor takk rettes til min kjære samboer Monica Smørås som både har korrekturlest oppgaven og som har vært en viktig støttespiller gjennom hele perioden bachelorprosjektet har pågått. Videre vil jeg påpeke at alle verktøy som er tatt i bruk i denne oppgaven er åpen kildekode, og dette har gitt meg stor frihet til å tilpasse disse etter behov. Alt mitt arbeid med denne oppgaven har blitt publisert offentlig og jeg håper at andre kan dra nytte av dette. Kristian Ådlandsvik Skurtveit Bergen, juni

4 Innholdsfortegnelse 1. Innledning og problemstillinger Oppdragsgiver Introduksjon til UH-skyprosjektet Fordeler for oppdragsgiver Problemstillinger Diskusjon rundt problemstilling Krav til monitoreringsverktøy Forventet resultat Opplæringsbehov Utviklingsmetode, arbeidsverktøy, programvare og hardware Bruk av analyse Risiko og risikohåndtering Tidsplan Teori og metode Skyteknologi Infrastruktur som tjeneste (IaaS) Plattform som tjeneste (PaaS) Programvare som tjeneste (SaaS) Kodedefinert infrastruktur OpenStack Monitorering Metoder og verktøy Arbeidsverktøy Valg av analyse Monitoreringsverktøy OpenStack Monasca Icinga - basert på Nagios Logstash, Elasticsearch og Kibana Graphite Grafana Ganglia Munin Statsd Dashing OpenStack-Ceilometer / Graphite publiseringsskript Utprøving og testing av verktøy Logstash, Elasticsearch & Kibana Statsd Dashing OpenStack-Ceilometer / Graphite publiseringsskript Graphite og Grafana Resultatmatrise av utført testing Diskusjon rundt anbefalt løsning Anbefalt monitoreringsløsning Kartlegging av kritiske og mindre kritiske tjenester Filtrering av unyttige data Implementering av anbefalt monitoreringsløsning Monitorering ved hjelp av Logstash hos andre aktører

5 4.5.1 Ebay Universitetet i Oslo GoDaddy Sammendrag, konklusjon og videre arbeid Sammendrag og konklusjon Videre arbeid Betraktninger rundt etikk- og personvernspørsmål Litteratur Vedlegg

6 1. Innledning og problemstillinger 1.1 Oppdragsgiver Oppdragsgiver for denne bacheloroppgaven er IT-avdelingen ved Universitetet i Bergen. ITavdelingen er UiBs hovedleverandør av standardiserte IKT-tjenester som støtter brukerne i sitt daglige virke. Avdelingen består av tre seksjoner som er infrastruktur, applikasjoner og brukerstøtte Introduksjon til UH-skyprosjektet IT-avdelingen ble i år 2014 deltager i et nasjonalt universitet- og høgskoleprosjekt om å implementere en IaaS-plattform (Infrastructure as a Service) som baserer seg på OpenStack. Denne plattformen er ment å være en fremtidig byggeblokk for IT-leveranser til UH-sektoren. Jeg arbeidet på IT-avdelingen høsten 2014 i forbindelse med utplasseringsfaget DAT156 og opparbeidet meg flere måneders verdifull erfaring og kunnskap om OpenStack i dette prosjektet, videre omtalt som skyprosjektet Fordeler for oppdragsgiver Bacheloroppgaven vil være av verdi for UiB og skyprosjektet ettersom oppgaven går ut på å levere et skreddersydd forslag til system som monitorerer OpenStack på best mulig måte i henhold til de krav og ønsker som UiB har stilt. Disse kravene er spesifisert i kapittel 1.4. Systemet vil kunne overvåke alle komponentene i OpenStack-rammeverket og vil være åpen kildekode. Åpen kildekode gir mulighet til å spesialtilpasse løsningen slik man måtte ønske. UiB har behov for et system som sikrer at nødvendig informasjon ikke går tapt eller overskygges av unødvendige data. Bacheloroppgaven vil være av stor betydning for dem som skal drifte OpenStack-rammeverket dersom min anbefalte løsning tas i bruk. Om det skulle oppstå feil på datasystemene vil bacheloroppgaven også være til hjelp ved feilsøking og problemløsning. Universitets- og høgskolesektorens skyprosjekt er et nasjonalt prosjekt som går på tvers av universitetene i Norge (UiO, UiT, NTNU, UiB). Mitt ønske er at den anbefalte monitoreringsløsningen fra oppgaven også vil være av verdi for de øvrige universitetene. Bacheloroppgaven vil også inneholde refleksjoner rundt ulike problemstillinger som er påtruffet underveis i arbeidet. Det er selvsagt ønskelig at monitoreringsløsningen som anbefales kan tas i bruk i sin helhet og være til nytte for tiltenkte brukere. 1.2 Problemstillinger Problemstillingene som skal besvares i bacheloroppgaven har jeg fått velge selv i samarbeid med IT-avdelingen og skyprosjektet. Jeg valgte å se på monitorering av OpenStack fordi dette ville gi muligheter til å gå i dybden på de enkelte komponentene rammeverket består av. Skyprosjektet hadde ikke noen konkrete planer for hvordan den ferdige plattformen skulle overvåkes. Derfor ble det et naturlig valg for meg å ha overvåking som bacheloroppgave. Jeg har derved fått mulighet til mye spennende læring, samtidig som jeg kan bidra med arbeid som vil få verdi for skyprosjektet. Hovedproblemstilling: Undersøke ulike monitoreringsløsninger og anbefale verktøy til overvåking av OpenStackrammeverket i universitets- og høgskolesektorens skyprosjekt. 6

7 Underproblemstillinger: Kartlegge forskjellige monitoreringsverktøy og teste bruken av disse. Belyse fordeler og ulemper med forskjellige overvåkingsverktøy. Hva passer best til skyprosjektet? Er det noen verktøy som er laget spesielt for skyovervåking? Anbefale verktøy og implementere dette. Se på oppbyggingen av OpenStack-rammeverket for å kartlegge hvilke komponenter som er: kritiske å overvåke. mindre kritisk å overvåke. Hvordan kan unyttige data filtreres bort for å få fram informasjonen som er nødvendig å vite? Gjøre betraktninger på etikk og personvern knyttet til monitorering av OpenStack. 1.3 Diskusjon rundt problemstilling OpenStack er et stort og komplekst rammeverk som består av mange tjenester og komponenter. Rammeverket genererer store mengder informasjon om alle hendelser som skjer på systemet. Informasjonen kan være brukere som logger inn, oppretting av instanser og nettverk, importering og lagring av data, nedlastning av nye operativsystembilder, samt bruker- og tjenestehåndtering. Hovedproblemet som skal løses er etter min vurdering tredelt. For det første er alle hendelsene generert av sin egen tjeneste på hver maskin i OpenStack-rammeverket. Det vil være en tilnærmet umulig jobb for en systemadministrator å holde oversikt over alt som skjer i OpenStack dersom feil skulle forekomme. Vedkommende ville vært avhengig av å sjekke logger manuelt for hver tjeneste for hver maskin kontinuerlig, noe som vil være svært uhensiktsmessig i lengden. Derfor er løsningen på det første problemet å sentralisere alle loggdataene slik at disse kan håndteres på et og samme sted. Det andre problemet er å separere informasjon fra alle loggdataene som blir samlet inn. I et slikt oppsett er det viktig å fastslå hvilke tjenester som er kritiske og hvilke tjenester som er mindre kritiske. Vi vil ha tak i den informasjonen som gir en best mulig oversikt over hvordan systemet fungerer til enhver tid. Ikke-kritisk informasjon som trace- og debugmeldinger kan i mange tilfeller overskygge den informasjonen man faktisk søker. Dette kan over tid føre til at viktige data går tapt og man ender i verste fall opp med at all informasjon fremstår som ubrukelig. Dette er selvsagt en situasjon som ikke er ønskelig, og det monitoreringsverktøyet som blir anbefalt må derfor kunne filtrere vekk unødvendige data. Det tredje problemet er å kunne visualisere de dataene som blir samlet inn. Dette er viktig for å kunne lage trender, telle hendelser, visualisere og manipulere data og ikke minst gir det muligheter til å være proaktiv slik at problemer kan forutses. Et eksempel i denne sammenheng kan være en harddisk som er i ferd med å gå full; Ved å overvåke harddiskens lagringskapasitet vites det på hvilket tidspunkt kapasitetsgrensen er nådd, og den kan byttes ut før problemer oppstår. Om man ser at antall brukerinnlogginger er økende for hver dag kan man på bakgrunn av tidligere innsamlede data beregne når det trengs ekstra kapasitet for å håndtere alle brukerne. Eksemplene ovenfor er data som kan visualiseres, noe som gir en kjapp og grei oversikt over det som skjer på systemet. Her kan man også følge med på hendelser over tid, håndtere potensielle feil før de oppstår og vise ulike data i sammenheng. I tillegg kan man på bakgrunn av grafene telle opp hendelser for å lage alarmer og notifikasjoner. Her kan det settes opp alarmer som varsler systemadministrator dersom en kritisk tjeneste skulle stoppe opp. Samtidig vil et notifikasjonssystem kombinert med visualiserte data være en fordel for videre problemhåndtering. Et slikt system vil også kunne sende ut varsel til 7

8 administrator via epost. 1.4 Krav til monitoreringsverktøy For å kunne implementere en god løsning for monitorering er det visse krav som må innfris. De forskjellige monitoreringsverktøyene som vurderes skal være: Anbefalte og populære blant store aktører Man skal kunne hente erfaringer fra andre og det skal være enkelt å skaffe hjelp dersom det skulle oppstå problemer med verktøyet Åpen kildekode for å kunne skreddersys til egne behov Løsningen skal være uten kostnad, og kunne spesialtilpasses til å monitorere OpenStack-spesifikke data Godt dokumentert og vedlikeholdt Verktøyet må inkludere tilgang til gode og oppdaterte hjelpesider og beskrivelser av funksjonalitet (eksempelvis installasjon og konfigurasjon) Løsningen skal oppdateres ofte og slik at feil og tidligere problemer blir rettet opp Styrbar ved hjelp av puppet som øvrige komponenter i skyprosjektet Verktøyet må kunne installeres og konfigureres ved hjelp av kode Et verktøy som ikke bruker agenter for datainnhenting Dette kom inn som et tilleggskrav etter at utprøvingen var påbegynt og dette medførte at verktøyet Icinga ble valgt bort. Med ovenstående krav tilfredsstilt blir dette en løsning av god kvalitet som kan brukes for flere år fremover. De verktøyene som blir vurdert kommer fra internettsiden wiki.openstack.org, som er en samleside for de verktøyene ulike aktørerer har brukt for å understøtte OpenStack-infrastruktur (wiki.openstack.org, u.d). 1.5 Forventet resultat Praksisen med å sentralisere loggdata, ekstrahere relevant informasjon og visualisere informasjon, har ikke vært i bruk på UiB tidligere. UiB ønsker å implementere dette for å komme på høyde med andre bedrifter / institusjoner det er naturlig å sammenligne seg med. I denne oppgaven introduseres derfor en praksis som forlengst er tatt i bruk andre steder. Arbeidet i denne oppgaven begrenses av metoder som allerede eksisterer og som kan skreddersys til skyprosjektet. Forventet resultat er at mitt bidrag til skyprosjektet vil være en anvendelig og fullverdig løsning for monitorering, og at dette kan tas i bruk sammen med de øvrige komponentene i skyprosjektet. 1.6 Opplæringsbehov Høsten 2014 var jeg utplassering på UiB i faget DAT156. Gjennom semesterets 5 måneder fikk jeg god kjennskap til OpenStack-rammeverket og underliggende komponenter og verktøy som et slikt rammeverk består av. Dette har gitt meg et solid grunnlag å bygge videre på og jeg har 8

9 kunnet tilegne meg den nødvendige kunnskap som trengs for å svare på problemstillingene. Det oppleves derfor positivt at UiB viste meg nødvendig tillit og som følge av dette har jeg fått tildelt en større oppgave enn det jeg ellers ville ha mulighet for å klare. Monitorering av skytjenester var nytt for meg og jeg fikk muligheten til å lære meg mange spennende ting i løpet av denne tiden. Det skal også nevnes at jeg måtte tilegne meg kunnskap både gjennom utplasseringsfaget og under arbeidet med bacheloroppgaven som ligger utenfor faglitteraturen på dataingeniørstudiet. 1.7 Utviklingsmetode, arbeidsverktøy, programvare og hardware Alt av programvare som tas i bruk er åpen kildekode. Under utplasseringen hos UiB høsten 2014 ble jeg godt kjent med Git (github.com, 2014a) som versjonskontrollsystem for kode, og har til nå i bacheloroppgaven arbeidet daglig i min egen branch på Github. Her tester jeg ulike monitoreringsverktøy og har i denne sammenheng valgt ut «Trello», «Vagrant, «Puppet», og «ReText» som arbeidsverktøy. Disse vil bli nærmere forklart i metodekapittelet. Testingen av de ulike monitoreringsverktøyene skjer i en virtuell plattform på min egen arbeidsstasjon. Når endelig monitoreringsløsning er blitt valgt vil testingen foregå på en fysisk blade-server av typen Dell m600. Serveren har tilgang til et utviklingsmiljø for OpenStackinstallasjonen til UiB, og på denne måten vil monitoreringsløsningen bli testet med data fra en «reell» driftssituasjon. 1.8 Bruk av analyse Jeg vil bruke komparativ- og kvalitativ analyse når utvalget og testingen av verktøyene vil bli gjort. Dette vil bli nærmere forklart i metodekapittelet. 1.9 Risiko og risikohåndtering Det vil alltid være risiko for at hendelser kan inntreffe i perioden arbeidet med bacheloroppgaven pågår. En slik hendelse kan eksempelvis være egen sykdom, som i verste fall kan medføre at arbeid kan bli utsatt. For å håndtere denne risikofaktoren har jeg skaffet meg VPN-tilgang til UiB. Om sykdom skulle inntreffe har jeg fortsatt mulighet til å kunne jobbe hjemmefra og vil ha tilgang til de samme ressursene som jeg ellers ville hatt. En annen risikofaktor er at selve skyprosjektet kan bli utsatt. Som kjent blir IT-prosjekter ofte forskjøvet og utsatt grunnet eksempelvis kompleksitet. I mitt tilfelle kan dette medføre at bacheloroppgaven ikke blir ferdig som planlagt innen rett tid, ettersom jeg trenger input fra resten av skyprosjektet for å kunne fullføre. Skulle dette inntreffe vil jeg bli nødt til å endre på eventuelle problemstillinger eller vinkling for likevel å kunne fullføre bacheloroppgaven. I et slikt tilfelle vil jeg også utvide punktet i avslutningskapittelet om videre arbeid, der jeg også vil diskutere rundt mulige resultater dersom jeg hadde hatt mer tid til rådighet Tidsplan Tidsplanen for bacheloroppgaven ligger som vedlegg 1. 9

10 2. Teori og metode 2.1 Skyteknologi Skyteknologi er en betegnelse for store grupper med servere som står i eksterne sentraliserte dataparker. I en slik datapark vil både bedrifter og privatpersoner ha mulighet til å leie prosessorkraft, lagring, nettverk og eventuelt andre maskinressurser etter behov. Nettskyer er ofte selvskalerende og det er mange selskaper som tilbyr skytjenester for sine kunder (Woodford, 2009). Det finnes i dag mange store aktører innenfor skytjenester, blant annet Amazon Elastic Compute Cloud, Microsoft Azure og Rackspace Open Cloud. Disse aktørene har implementert både IaaS, SaaS og PaaS og tilbyr dette til sine kunder. Skyprosjektet på Universitetet i Bergen skal implementere en Infrastruktur som tjenesteplattform basert på OpenStack og skal tilby dette til universitet- og høgskolesektoren. Figur 2.1-1: Cloud Computing (Johnston, 2009) Infrastruktur som tjeneste (IaaS) Infrastruktur som tjeneste (Infrastructure as a Service) er «muligheten til å leie prosessorkraft, lagring, nettverk og andre fundamentale maskinressurser hvor kunden er i stand til å opprette, lagre data og/eller kjøre vilkårlig programvare. Dette inkluderer operativsystem og applikasjoner» (uninett.no, 2014). 10

11 2.1.2 Plattform som tjeneste (PaaS) Plattform som tjeneste (Platform as a Service) er muligheten til å rulle ut applikasjoner laget av forbrukeren i en skyinfrastruktur med støtte for et eller flere programmeringsspråk med varierende rikdom i underliggende funksjonsbibliotek og knytning til lisensbetingelser. «Her forholder ikke forbrukeren seg direkte til operativsystem eller lagring, men muligens til forskjellige ferdiglagde konfigurasjoner for applikasjons-hosting» (uninett.no, 2014) Programvare som tjeneste (SaaS) Programvare som tjeneste (Software as a Service) er «muligheten til å bruke tilbyders applikasjon som kjører i en skyinfrastruktur og er tilgjengelig fra et utvalg av tynnklient-grensesnitt som for eksempel en nettleser, og/eller apper på nettbrett og mobiltelefoner. Med unntak av helt brukerspesifikke innstillinger styrer ikke brukeren av tjenesten de underliggende elementene I skyinfrastrukturen eller eventuelle rammeverk applikasjonen er bygget i» (uninett.no, 2014). 2.2 Kodedefinert infrastruktur Alt av programvare, maskiner, operativsystem blir installert og konfigurert ved hjelp av programmert kode. Når anbefalt monitoreringsløsning foreligger vil denne også bli installert kodemessig (Marschall, 2010). 2.3 OpenStack OpenStack er et åpent kildekoderammeverk som styrer store mengder med compute-, lagrings- og nettverksressurser gjennom et datasenter. Alt av OpenStack-komponenter styres ved hjelp av et web-basert kontrollpanel som gir brukere tilgang til å provisjonere de ressursene som trengs i form av virtuelle maskiner. I tillegg til å bli styrt gjennom kontrollpanelet kan man også bruke OpenStack sitt innebyggede API eller kommandolinjeverktøy. OpenStack består av tre hovedkomponenter, compute, nettverk og lagring: Computenoden og dens tjenester er den komponenten som er ansvarlig for å styre de virtuelle maskinene og tilbyr funksjonalitet i forhold til dette. Nettverksnoden holder kontroll på de forskjellige nettverkene som støttes, og viser en hierarkisk oversikt over hvordan nettverkene er bygget opp innad i skyen. Lagringsnoden tilbyr lagring som de andre nodene i OpenStack skal kunne benytte seg av. Lagringen er delt opp i to større deler, objektbasert lagring og den mer tradisjonelle lagringen som er blokkbasert (openstack.org, 2014). 11

12 Figur 2.2-1: OpenStack Software Diagram (openstack-software-diagram, u.d). 2.4 Monitorering Monitorering kan kort oppsummeres som et system som overvåker andre systemer. Om en feil skulle skje på nettverket eller at en server skulle «gå ned» ville systemadministratorene bli varslet om dette. Det finnes mange monitoreringsløsninger som benyttes i dag. De fleste bedrifter har gjerne bare et system som overvåker infrastrukturen, mens andre bedrifter ofte bruker flere verktøy og skreddersyr i tillegg verktøyene for å tilpasses de tjenestene de drifter (compnetworking.about.com, 2014). 2.5 Metoder og verktøy De ulike arbeidsverktøyene blir presentert først, deretter vil monitoreringsverktøy bli presentert Arbeidsverktøy Trello Trello er et prosjektstyringsverktøy som er basert på prinsippet med «gule lapper». Verktøyet gir en enkel oversikt over de ulike aktivitetene som til enhver tid foregår i et prosjekt. I hovedsak ligger alle aktivitetene under tre hovedkategorier; «To Do», «Doing» eller «Done». Deltakerne i prosjektet blir enten tildelt en aktivitet fra prosjektleder eller de tildeler aktiviteten til seg selv. Når en deltaker begynner på aktiviteten flyttes den til «Doing». I hver aktivitet kan alle prosjektdeltakerne delta med kommentarer, filer og oppdateringer (trello.com, 2014). Figur : Trello-oversikt (home-hero, u.d). 12

13 Vagrant / Virtualbox Vagrant er et åpent kildekodeverktøy for å installere og provisjonere virtuelle testmaskiner. Dette blir ofte sett på som en wrapper rundt virtualiseringsplattformer, i dette tilfellet VirtualBox. I et slikt virtuelt miljø er det større frihet på hva man kan gjøre på operativsystemet i forhold til en fysisk maskin. Man kan slette filer man vanligvis ikke ville slettet, og teste ut sære løsninger. Om ting skulle gå galt kan man enkelt slette maskinen og starte den på nytt. Ved hjelp av vagrant kan man få en ferdig maskin installert i løpet av få minutter. Eventuelle tilpasninger og programvare kan spesifiseres på forhånd slik at maskinen starter opp med dette installert. Da slipper man å bruke tid på å gjøre slike tilpasninger i etterkant og det er svært gunstig å kjøre testmiljøer ved hjelp av et slikt verktøy (vagrantup.com, 2013). Puppet Puppet er et system for å sentralisere, standardisere og administrere IT-infrastruktur. Puppet tillater en systemadministrator å definere en ønsket tilstand på infrastrukturen i organisasjonen. Deretter blir denne tilstanden automatisk opprettholdt med gitte mellomrom. Tilstandene blir definert med en rekke puppet-moduler som kommer fra en sentralisert puppetmaster (puppetlabs.com, 2014, linux.com, 2010). Når anbefalt monitoreringsløsning foreligger vil disse bli installert kodemessig ved hjelp av puppet. ReText ReText er enkelt men kraftig tekstredigeringsverktøy som brukes for å skrive dokumentasjon som ligger på Github. Programmet inneholder blant annet en nyttig forhåndsvisningsfunksjon som lar brukeren se hvordan dokumentasjonen vil se ut på Github uten at selve dokumentet må åpnes i en nettleser. Når anbefalt monitoreringsløsning foreligger vil ReText bli benyttet for å dokumentere hvordan løsningen skal brukes sammen med OpenStack (sourceforge.net, 2014) Valg av analyse Kravene som ble spesifisert i kapittel 1.4 gir en begrenset utvalgskrets for videre kvalitativ analyse av de enkelte verktøyene. Dette gir grunnlag for å gå i dybden og teste de resterende verktøyene i detalj (Oates 2006: ). Derpå følger en komparativ analyse av de utvalgte verktøyene, hvor de sammenliknes opp mot problemstillingene (wikipedia.org, 2014). For å gå i dybden på de ulike verktøyene vil jeg i tillegg ta i bruk dokumentanalyse. Jeg vil studere elektroniske dokumenter for å finne den informasjonen som trengs for å kunne utføre den komparative analysen (Oates 2006: 43-51, ). Ønsket resultat av analysene vil være et verktøy, eventuelt kombinasjon av flere verktøy, som er mest hensiktsmessig til monitorering av OpenStack Monitoreringsverktøy Som nevnt i delkapittel vil de ulike monitoreringsverktøyene bli sammenlignet opp mot problemstillingene. Nedenfor følger derfor den kvalitative analysen av de ulike verktøyene OpenStack Monasca OpenStack Monasca er et åpent kildekodeverktøy som bygger på prinsippet «monitorering som tjeneste» (Monitoring as a Service), og integreres med OpenStack. Verktøyet prosesserer store mengder hendelser per sekund og tilbyr detaljert lagring av data uten tap, opp til et år. Monasca benytter et innebygget Restful API for å lagre, prosessere og kjøre spørringer på hendelser som 13

14 skjer i OpenStack. Disse dataene blir lagret og sendt til grafverktøyet Grafana slik at en kan få en visuell oversikt over hendelser som forekommer på systemet. Alle data er i sanntid, noe som gjør at man får en god oversikt over hva som skjer. Monasca blir integrert i OpenStack gjennom dashbordet Horizon. Her vil alle som har tilgang få mulighet til å sette opp egendefinerte alarmer og notifikasjoner. Monasca er designet for høy ytelse, skalerbarhet og tilgjengelighet. I tillegg er verktøyet laget uten bruk av noen spesielle protokoller og bruker kun http-protokollen for datainnhenting. Figur illustrerer Monasca integrert i OpenStack. Figur : Monasca komponentdiagram (Monasca-arch-component-diagram, u.d.) For øyeblikket finnes det ikke Monasca-støtte for RedHat-baserte linuxdistribusjoner. Stackforge, som er utvikleren av puppet-modulen for Monasca, har basert modulen på Ubuntu/Debian. Dette har medført at enkelte komponenter har blitt hardkodet til å støtte kun denne plattformen. Modulen kan ikke uten videre skrives om til å støtte RedHat, som er den linuxdistribusjonen som skyprosjektet skal kjøre på. Likevel må ikke Monasca utelukkes som et fremtidig monitoreringsverktøy for OpenStack, dette fordi det ifølge launchpad.net 1 har blitt satt av ressurser for å utvide verktøyet til å støtte RedHat-baserte linuxdistribusjoner. Imidlertid er det foreløpig ikke satt noen utgivelsesdato for dette. Ettersom Monasca ikke er støttet for øyeblikket blir ikke dette verktøyet tatt videre til utprøving (wiki.openstack.org, 2014) Icinga - basert på Nagios Utviklerne av Icinga bygger sitt monitoreringssystem på en kopi på det kjente 1 Launchpad.net er en webapplikasjon og en webside som lar brukerne utvikle og vedlikeholde programvare. 14

15 monitoreringsverktøyet Nagios. Nagios er et av de lengstlevende monitoreringsløsningene på markedet og det finnes mye kunnskap, dokumentasjon og erfaringer å hente fra aktører som har tatt dette verktøyet i bruk. Icinga ble kopiert fra Nagios' kodebase for å ta hånd om kjente problemer og for å implementere funksjonalitet som var ønsket av flere brukere av verktøyet. Det oppsto likevel flere problemer med Icinga som verktøy og disse problemene hadde sin opprinnelse fra Nagios. For å løse disse problemene og for å unngå komplikasjoner med Icinga, ble Icinga 2-prosjektet skapt. Dette var en ny versjon av monitoreringssystemet som kunne utvikles uavhengig av tidligere problemer og versjoner. Nå foregår utviklingen i to kodebaser uavhengig av hverandre, slik at endringer på verktøyene ikke påvirker brukerne som benytter den gamle versjonen. Disse brukerne får fortsatt tilgang til oppdateringer for å sikre at funksjonaliteten opprettholdes på dagens nivå. Icinga er fortsatt en kopi av Nagios og mye av den samme hovedfunksjonaliteten er beholdt. Blant annet har den nye versjonen bakover-kompatibilitet som gjør at tilleggsfunksjonalitet som fungerte i Nagios og den første versjonen av Icinga fortsatt fungerer i den nye versjonen. Dette har vært en stor fordel for alle som har erfaring med Nagios og gjort det svært enkelt for mange brukere å bytte til Icinga som monitoreringløsning. Systemet baserer seg på at man har en overvåkingsmaskin eller en klynge av overvåkingsmaskiner installert i nettverket sitt. Videre blir det installert overvåkingsagenter på de systemene man vil overvåke sammen med en konfigurasjonsfil. I denne filen spesifiserer man de tjenestene som ønskes overvåket og på bakgrunn av dette vil agenten rapportere status om tjenesten ved gitte intervaller og rapportere dette tilbake til overvåkingsmaskinen. Dersom det skulle oppstå feil på en tjeneste vil systemet rapportere om dette. Deretter må man logge inn på den aktuelle maskinen for å rette opp feilen. Icinga vil fortsette med intervallsjekkingen mot den samme maskinen som tjenesten kjørte. Dersom tjenesten kommer opp igjen endrer statusen seg og tjenesten blir rapportert som fungerende. Alt i Icinga blir administrert gjennom et webgrensesnitt. Her kan alarmer og notifikasjoner settes opp, samt at man kan søke i historikk og generere rapporter (icinga.org, 2015). Etter å ha kommet så langt i prosjektarbeidet ankom imidlertid varsel om skjerpede krav fra UiB, ved at bruk av agenter ikke var ønskelig fordi dette medfører unødvendig belastning på OpenStacktjenerne. Ettersom Icinga bruker agenter for datainnhenting vil følgelig dette verktøyet ikke bli tatt videre til utprøving fordi det ikke lenger følger kravene Logstash, Elasticsearch og Kibana Logstash er et åpent kildekodeverktøy som håndterer hendelser og logger. Verktøyet tar imot logger, ekstraherer informasjon og lagrer denne informasjonen for senere bruk. Logstash kan integreres mot en rekke andre verktøy som bruker informasjonen som er lagret til å visualisere og presentere data. Brukerne av verktøyet kan da logge inn på et webgrensesnitt og enkelt søke på data som er blitt samlet inn. I tillegg kan det settes opp grafer, kakediagram, histogram og andre former for datavisualisering. Logstash-konfigurasjonen benytter seg av tre hovedelementer, et inputelement, et filterelement og et outputelement. Inputelementet forteller hvor de ulike dataene kommer fra. Filterelement henter ut informasjonen vi ønsker fra loggfilene og deler opp loggmeldingene til separate felt. Outputelementet sender informasjonen som er blitt samlet inn, til flere ulike systemer og visualiseringsverktøy. Inputelementet til Logstash kan konfigureres til å ta imot data fra mange ulike kilder, og dette gjør verktøyet svært aktuelt å bruke i forbindelse med sentralisering av loggdata. I kombinasjon med filterelementet som henter ut ønsket informasjon vil Logstash kunne løse to av de tre problemene som ble nevnt i diskusjon rundt problemstilling i kapittel 1.3. Oppsettet mange aktører bruker sammen med Logstash er verktøyene Elasticsearch og Kibana. Elasticsearch er et av mange verktøy som kan konfigureres til å ta imot data fra Logstash sitt outputelement. 15

16 Elasticsearch vil lagre informasjonen etter at den er ferdig filtrert i Logstash og kan settes opp både enkeltvis eller i klynger. Videre kan alle data som har blitt hentet ut gjennom Logstash søkes opp i et grafisk webgrensesnitt som heter Kibana. I dette grensesnittet kan man sette opp indekserte søk på spesifikk informasjon, visualisere data, samt lage kakediagram og histogrammer. Alle data som fremkommer i systemet kan søkes opp med hensyn på tid når dataene ble generert. Eksempelvis kan man vise data fra de siste 5 minuttene eller man kan spesifisere at man ønsker å se data tilbake i tid. Det å kunne se data i denne sammenheng gir systemadministratorene mulighet til å se hvordan data utvikler seg over tid og hva som skjer i OpenStack fra dag til dag (elastic.co, 2015a). Selv om alle hendelser og loggdata blir lagret i Elasticsearch og visualisert gjennom Kibana vil det også være hensiktsmessig å lagre alle loggene som kommer inn på systemet. I et driftsmiljø ønsker man å kunne lagre logg på harddisken for en gitt periode. Dette for å kunne gå tilbake i tid for eksempel hvis en bruker har rapportert inn en feil som ikke har blitt fanget av filtrene i Logstash. Da vil filtrene kunne endres slik at feilen som ble rapportert vil oppdages automatisk av systemet dersom den skulle skje igjen. Over tid vil man på denne måten klare å håndtere de fleste feil som kan oppstå. I tillegg er lagring av logg for en gitt tidsperiode viktig dersom brukerne i OpenStack ikke skulle rapportere inn feil umiddelbart. Oppsummert er Logstash et aktuelt verktøy å bruke når det kommer til monitorering av OpenStack, ettersom det løser problemet rundt datasentralisering og ekstrahering av ønsket informasjon. Samtidig har verktøyet en stor fordel sammenlignet med de fleste andre monitoreringsverktøy. Det er ikke avhengig av å bruke agenter for datainnhenting, men får istede tilsendt data fra flere ulike kilder. Ved å bruke Logstash i kombinasjon med Elasticsearch og Kibana blir de sentraliserte dataene også bli lagret for senere bruk, i tillegg til at dataene kan visualiseres på flere forskjellige måter. På bakgrunn av dette vil disse tre verktøyene bli tatt videre til utprøving Graphite I tillegg til å samle inn data fra ulike kilder i OpenStack-rammeverket ønsker man også å kunne lage grafer for enkelte av disse dataene. Dette er viktig for å lage trender og for å se data i sammenheng. Istedenfor å feilsøke mengder av pakkeforespørsler på nettverket som en separat hendelse, velger man å se dette sammen med nettverkstrafikk generert av instansene i OpenStack. I slike scenarier blir verdien av grafing tydeliggjort. Over tid blir man svært vant med hvordan data «skal» se ut og hvis det forekommer avvik eller hendelser som gjør at grafen ser annerledes ut en forventer, vet man at noe har skjedd. Det er her verktøyet Graphite kommer inn i bildet. Graphite er et åpent kildekodeverktøy, høyt skalerbart sanntids grafsystem designet for å håndtere numeriske tidsserier med data som man ønsker å visualisere. Graphite er et komplekst system som er laget for å håndtere store mengder data og dette skiller seg klart ut som en av fordelene med verktøyet. Siden OpenStack kan generere flere millioner linjer loggdata der vi har ulike hendelser som skal kunne grafes på en eller annen måte, er det en fordel at Graphite takler dette uten problemer. Videre kan Graphite konfigureres til å ta imot data fra en rekke andre verktøy, deriblant Logstash. I tillegg er grafene i Graphite i sanntid, noe som er svært viktig for å forutse feil og for å se problemer når de oppstår (graphite.wikidot.com, 2009). Siden Graphite kan motta data direkte fra Logstash kan data visualiseres på flere ulike måter enn ved bruk av Kibana alene. Dette gjør at Graphite er et aktuelt verktøy å bruke for datavisualisering og blir derfor tatt videre til utprøving. 16

17 Grafana Webgrensesnittet til Graphite bærer preg av å være gammelt og lite intuitivt å bruke. Informasjonen blir ikke presentert på en ryddig og oversiktlig måte og en kan fort miste oversikten i verktøyet. Dette er imidlertid ikke noe hinder da Graphite er svært konfigurerbart når det kommer til installasjon av andre webgrensesnitt. I denne sammenheng er det mange som bruker et grafverktøy som heter Grafana, som kan installeres side om side med Graphite. Alt av data som er lagret i Graphite-databasen kan grafes i Grafana på den måten man måtte ønske. Grafana er et kjent verktøy og er tatt i bruk av flere store aktører, deriblant Vimeo, NetApp, og Rackspace. Grafana tilbyr oppsett av egendefinerte dashbord og informasjonen blir presentert på en oversiktlig og strukturert måte. På bakgrunn av dette blir også Grafana tatt videre til utprøving (grafana.org, 2013). Figur : Memory / CPU usage graph (mixed-styles, u.d.) Ganglia Ganglia er et skalerbart, distribuert monitoreringssystem laget for å overvåke klynger og grids. Verktøyet har blant annet blitt brukt til å koble sammen klynger på universiteter og er i bruk på flere tusen klynger verden rundt. Grafene i verktøyet er blitt laget ved hjelp av et verktøy som heter RRDtool, og grafene blir laget for hver time, hver dag, hver uke, hver måned og hvert år. Grafene kan aksesseres gjennom et eget webgrensesnitt, og en kan herfra søke seg ned på detaljnivå for hver av tjenestene man overvåker. Totalt støtter verktøyet klynger med opptil 2000 noder og bruker en egen agent for datainnhenting som installeres på de klyngene man vil overvåke. Grafene i Ganglia er ikke i sanntid noe som gjør at man ikke kan se feil når de oppstår (ganglia.info, u.d). Ganglia vil ikke bli tatt videre til utprøving ettersom det bruker agenter for innhenting av data i tillegg til at data ikke er i sanntid Munin Munin er et monitoreringsverktøy som analyserer ressurstrender og er laget for å være enkelt og fort å komme i gang med. Verktøyet benytter seg av RRDtool for skriving av grafer og alle grafene kan sees gjennom et webgrensesnitt. Munin er skrevet i Perl, og støtter tilleggsfunksjonalitet i de aller 17

18 fleste skript- og programmeringsspråk. Munin kjører med en grunninnstilling for hente data hvert 5 minutt, og denne verdien kan både justeres opp og ned. Likevel vil ikke data som presenteres i systemet være i sanntid, dette fordi RRDtool bare lager grafer med utgangspunkt i 5-minuttersdata. Systemet avhenger også av agenter for datainnsamling, i tillegg til at tilleggsfunksjonalitet må legges til på hver maskin som blir overvåket. At tilleggfunksjonalitet må legges til på denne måten gjør at vedlikeholdet av Munin kan bli tungvint dersom man overvåker store nettverk. Oppsummert er Munin et svært konfigurerbart verktøy som kan grafe det aller meste av data, men på grunn av agentbruk i datainnhentingen og at administrasjonen av verktøyet kan bli tungvint, tas ikke verktøyet videre til utprøving (munin-monitoring.org, 2014) Statsd Statsd er en prosess som fanger opp innkommende statistikk (tellere, timere) sent over UDP eller TCP og lagrer dette i en eller flere konfigurerbare systemer, for eksempel Graphite. Statsd tilbyr tilleggsfunksjonalitet i forbindelse med visualisering av data sent fra Logstash, men kan også benyttes til å visualisere data som kommer fra skript og andre datakilder. På bakgrunn av dette virker Statsd som et interessant verktøy og på grunn av økt visualiseringsfunksjonalitet tas verktøyet videre til utprøving (github.com, 2014b) Dashing Dashing er et rammeverk som lar brukerne spesialtilpasse og bygge dashbord for å visualisere informasjon. Data som skal visualiseres på dashbordet kan enten sendes ved hjelp av skript eller ved å benytte seg av Dashings' innebyggede API. Under kartleggingen av dette verktøyet ble det funnet et ferdig konfigurert dashbord som kunne implementeres på kort tid, for å visualisere ressursbruk i OpenStack. På grunnlag av dette tas verktøyet videre til utprøving (dashing.io, 2015) OpenStack-Ceilometer / Graphite publiseringsskript Ceilometer er en tjeneste innad i OpenStack som genererer statistikk og ressursbruk fra de andre tjenestene i rammeverket. I denne sammenheng har det blitt laget et publiseringsskript som sender data til Graphite om de forskjellige instansene og deres ressursbruk (Leeuwen, 2009). Dette er data som er viktig å visualisere dersom det skulle oppstå feil på instansene i OpenStack. I tillegg vil disse dataene kunne tilgjengeliggjøres for brukere av OpenStack, slik at de kan følge med på eget ressursbruk. Med bakgrunn i dette tas publiseringsskriptet videre til utprøving. 18

19 3. Utprøving og testing av verktøy I utgangspunktet kunne det være ønskelig at det var flere monitoreringsverktøy som ble tatt videre til utprøving, men på grunn av tilleggskravet fra UiB er det kun Logstash som tas med videre som hovedverktøy. Hvis testingen av verktøyet viser seg ikke å løse problemene diskutert i kapittel 1.3, blir UiB nødt til å fire på noen krav slik at flere monitoreringsverktøy eventuelt kan vurderes. Imidlertid har jeg hørt mye bra om Logstash som verktøy og ble i begynnelsen av bacheloroppgaven rådet til å kikke på dette. Logstash er i bruk på andre universiteter til lignende type formål og jeg har derfor stor tro på at testingen vil gi ønskede resultater i forhold til problemstillingene som skal besvares. Når det kommer til visualiseringsverktøy er det flere av disse som har blitt tatt videre til utprøving. Skulle Logstash vise seg å være et godt verktøy for monitorering for UiB vil kompatibiliteten til dette verktøyet være viktig for eventuelle visualiseringsverktøy som velges. Nedenfor er en oversikt over de ulike verktøyene som har blitt tatt videre til utprøving og hvilke deler av problemstillingene de kan løse: Sentralisering og lagring av data, samt ekstrahering av relevant informasjon: Logstash, Elasticsearch, OpenStack-Ceilometer og Statsd. Visualisering av data: Kibana, Graphite, Grafana, Dashing og publiseringsskriptet. 3.1 Logstash, Elasticsearch & Kibana Som nevnt i forrige kapittel benytter Logstash seg av en konfigurasjonsfil med tre hovedelementer. Her blir ulike inputkilder definert og filtre for inputkildene konfigurert, før all informasjonen som er hentet ut blir videreført til forskjellige systemer gjennom outputelementet. I denne prosessen kan man ved hjelp av filterelementet ekstrahere ønsket informasjon ved hjelp av forskjellige metoder, og manipulere informasjon som det er behov for å omorganisere. I tillegg kan det filtreres vekk informasjon som er unødvendig. For å kunne ekstrahere relevant informasjon fra OpenStack-rammeverket er det nødvendig å vite noe om dataene på forhånd. Alle de ulike tjenestene rammeverket består av bruker et standardisert oppsett når hendelser skal logges og skrives til filsystemet. Nedenfor følger et utdrag fra en av tjenestene i OpenStack: T05:18:38+00:00 compute :18: INFO keystoneclient.middleware.auth_token [-] Når alle hendelser blir logget på denne måten kan vi ut fra dette fastlå at følgende informasjon alltid forekommer: Et tidsstempel, et hostnavn, et nytt tidsstempel, prosessidentifikator, loggnivå og tjeneste. Etter dette varierer dataene etter hva type hendelse det er. For eksempel sier følgende logglinje at en instans i OpenStack er blitt satt til «state error»: T12:29:43+00:00 controller :29: WARNING nova.scheduler.driver [req-2235b194-e76d bcb-1b7080f54ae9 8d496d145b7b4e5fa84e107548f905ad 62e82d58809d4c2da11019dbba2b8f14] [instance: e189c4ed-fa31-477f-9207-ad6a3d64e8a3] Setting instance to ERROR state. Basert på denne hendelsen kan det lages filtre i Logstash-konfigurasjonen som brukes til å 19

20 ekstrahere ønsket informasjon. Under utprøving av Logstash som verktøy ble det laget et generelt filter som håndterer de fleste typer hendelser som forekommer i en OpenStack-logg. Det finnes mange forskjellige måter å gjøre dette på, men den beste måten er ved bruk av grok-filtre. Grokfiltre fungerer slik at man lager tekstmønstre til noe som matcher de loggene man ønsker å filtrere. Grok er bygget på toppen av regulære uttrykk (Friedl, 2006: 1-33) og tilbyr 120 tekstmønstre som kan benyttes i filtrene for datauthenting (elastic.co, 2015b). Hvis det ikke finnes et filter for informasjonen man ønsker å ekstrahere er det enkelt å lage dette filteret selv, noe som gjør datauthentingen svært effektiv. Med utgangspunkt i hendelsen ovenfor kan man ved hjelp av et slikt filter forvandle hendelsen til et mer lesbart format som illustrert i figur Figur Instans i «state error» (egenprodusert figur fra Kibana) Denne informasjonen lagres deretter i Elasticsearch for videre bruk. Gjennom verktøyet Kibana kan denne informasjonen søkes opp og indekseres i et webgrensesnitt. Data kan settes i sammenheng, og Kibana muliggjør visualisering av data på flere ulike måter. Eksempelvis kan det visualiseres hvor ofte de ulike loggnivåene forekommer, og hvilke OpenStack-tjenester som genererer dem. I tillegg kan man ved hjelp av et slikt verktøy enkelt kartlegge hvilken informasjon som er viktig og hvilken informasjon som er mindre viktig. Eksempelvis er ikke loggmeldinger med «loading openstack extensions» i loggnivå «audit» særlig viktig, og det bør vurderes om denne informasjonen bør filtreres bort. I figur ovenfor er instansen som blir satt til «state error» med loggnivå «warning» mye viktigere. At instansen feiler kan være tegn på manglende ressurser, feil under opprettelsen av instansen eller andre relaterte faktorer. Her blir man nødt til å se denne feilen i sammenheng med andre hendelser som kan ha skjedd innenfor det aktuelle tidsrommet. Over tid vil man på samme måte som med grafing bli vant med hvordan data skal «se ut» og på denne måten kunne spore avvik fra normen. Skjer det hendelser som genererer feil må man ha rutiner på hvordan disse skal håndteres og rettes opp. Uttestingen viser at Logstash, Elasticsearch og Kibana er en svært god kombinasjon av verktøy som kan brukes til monitorering av OpenStack. Verktøyene kan skreddersys til å håndtere de fleste typer hendelser som forekommer i loggdata og andre inputkilder. For å hente informasjon på en kjapp og effektiv måte er det et krav at man vet hvordan dataene ser ut på forhånd, i tillegg til at disse følger en viss standard. Det er også nødvendig med basiskunnskaper om regulære uttrykk for å forstå hvordan filtre best mulig bør skrives for å få ut ønsket informasjon. Dette arbeidet blir etter hvert redusert når man har et datagrunnlag å bygge videre på. Da vet man mer om dataene som skal håndteres og eventuelle spesialtilpasninger blir lettere å implementere. 20

21 3.2 Statsd Statsd ble testet ut i kombinasjon med Logstash fordi verktøyet gir utvidede visualiseringsmuligheter når det kommer til grafing av data fra OpenStack. Statsd defineres i Logstash-konfigurasjonen som en output og tillater at hendelser og verdier kan telles, økes, minskes eller holdes på. Eksempelvis kan en OpenStack API-forespørsel som vist på figur kunne visualiseres ved hjelp av følgende konfigurasjon: if ([nova_api_request] =~ /(?i)"get "POST "DELETE/) { statsd { timing => ["nova.api.response", "%{nova_response_time"] increment => "%{nova_response_code" Figur Nova API-responsgraf (egenprodusert figur fra Grafana) Utprøvingen viser at Statsd er et konfigurerbart og enkelt verktøy å bruke. Det fungerer bra sammen med andre verktøy som Logstash og Graphite og data kan visualiserers som vist i figur

22 3.3 Dashing Siden det allerede fantes et dashbord som var laget for å visualisere data som kommer fra OpenStack, var Dashing et verktøy som var kjapt og enkelt å teste ut. Verktøyet krevde en bruker med administratorrettigheter og på den måten kunne man visualisere den totale ressursbruken i OpenStack uten videre konfigurasjon. Dette gjaldt også for et dashbord som var laget for å visualisere statusen på en Ceph-klynge, som er en lagringsteknologi som skal brukes i skyprosjektet. Figurene og viser hvordan dashbordene ser ut. Figur Dashing OpenStack (Rocha, 2014) Figur Dashing Ceph (egenprodusert figur fra Dashing) 22

23 3.4 OpenStack-Ceilometer / Graphite publiseringsskript OpenStack-Ceilometer kan konfigureres til å sende sine lagrede statistikker om ressursbruk til ulike kilder. Tjenesten har flere publiseringsverktøy innebygget og ved å legge til Graphite i tjenestens konfigurasjonsfil kan spesifikke instansdata sendes direkte til Graphite og visualiseres. Figur illustrerer noen av instansdataene som blir grafet. Figur Nettverksdata i en instans (egenprodusert figur av nettverkstrafikk i en instans) 3.5 Graphite og Grafana Det å kunne generere grafer av forskjellige hendelser, sette opp trender og se hvordan data utvikler seg over tid, er ønskelig i enhver driftssituasjon. Grafverktøyene Graphite og Grafana ble begge tatt med videre til utprøving fordi de tilbyr den funksjonaliteten som er ønsket i forhold til de dataene som skal visualiseres. I motsetning til lignende systemer som ble vurdert tidligere er grafene som disse verktøyene lager, i sanntid. Fordelen med dette er at vi kan se umiddelbare utslag i grafene dersom noe unormalt er i ferd med å skje, eller dersom en feil er pågående. Når det kommer til brukergrensesnittet til verktøyene tilbyr Graphite i seg selv begrensede muligheter til å manipulere grafer og oppsett av differensierte dashbord. Grafana er derimot mye bedre på dette området, og grafer og dashbord kan manipuleres med en rekke funksjoner for å presentere dataene på ønskelig måte. Eksempelvis tilbyr Grafana oppsett av matematiske funksjoner som derivasjon og integral for å vise stigning på et punkt, samt summering av hendelser innenfor gitte tidsintervaller. Under testingen av grafverktøyene har det blitt generert grafer basert på data fra Logstash, i tillegg til grafer som kommer fra ulike skripts og manuelle operasjoner på kommandolinjen. Det at Graphite har eksistert lenge på markedet gjør at andre programmer og verktøy har innebygget støtte for å sende data til dette grafsystemet. Dette gjør at data fra mange ulike kilder kan kombineres og gi et oversiktlig bilde over systemet og dets komponenter, i tillegg til å sette ulike data i sammenheng. 3.6 Resultatmatrise av utført testing Tabellen under gir en oversikt over resultatene fra testingene. Matrisen er satt opp for å bedre synliggjøre resultatene opp mot problemstillingene, og vise visualiseringsverktøyenes kompabilitet med Logstash. 23

24 Tabell 3.6-1: Resultatmatrise av utført testing. Verktøy: Logstash, Elasticsearch Sentralisere data Uthenting av relevant info Problemstillinger: Visualisering Kompabilitet med Logstash X X - NA Kibana X NA X X Graphite publiseringsskript X NA X - Statsd NA NA X* X Graphite og Grafana NA NA X X Dashing NA X X - NA = Not applicable X = Støttet - = Ikke støttet *Brukes til å utvide visualiseringer sendt fra Logstash. 24

25 4. Diskusjon rundt anbefalt løsning De tre hovedproblemene som skal løses i forbindelse med monitorering av Openstack er datasentralisering, datauthenting og visualisering av ekstrahert informasjon. Det finnes ikke ett enkeltstående monitoreringsverktøy som kan tjene alle formålene nevnt ovenfor, og den anbefalte løsningen blir derfor en kombinasjon av flere ulike verktøy. I kapittel 2 ble forskjellige monitoreringsverktøy introdusert og kartlagt med utgangspunkt i krav fra UiB. Videre i kartleggingen kom UiB med et tilleggskrav som medførte at verktøy som benyttet seg av agenter måtte velges bort. Verktøyene en satt igjen med ble sammenlignet opp mot problemstillingene, og siden alle verktøyene løser en eller flere deler av problemstillingene ble de tatt med videre til utprøving. 4.1 Anbefalt monitoreringsløsning Utprøvingen av de forskjellige verktøyene viser at kombinasjonen Logstash, Elasticsearch og Kibana er det som vil passe best til skyprosjektet. Med disse verktøyene kan data som genereres av OpenStack sentraliseres, ønsket informasjon kan hentes ut på en effektiv måte og informasjonen kan lagres for videre bruk. Deretter kan informasjonen visualiseres på ulike måter gjennom webgrensesnittet Kibana. Ved utprøving av Logstash kom det fram av dokumentasjonen at verktøyet støttet utsending av data til flere ulike visualiseringsverktøy, og disse verktøyene ble da hentet inn der det ble behov for dette. Underveis i utprøvingen ble ingen av visualiseringsverktøyene forkastet, og det er kun Dashing og publiseringsskriptet som vil brukes i sin helhet. Når det gjelder verktøyene Statsd og Graphite vil kun deler av funksjonaliteten fylle en funksjon i det endelige oppsettet for monitorering, mens øvrige deler av disse verktøyene ikke vil bli tatt i bruk. Logstash, Elasticsearch og Kibana vil konfigureres sammen med Statsd og Graphite og på denne måten tilby utvidet visualiseringsfunksjonalitet. Data vil kunne ses på i større sammenheng, mer detaljerte trender og tellere kan settes opp, samt at data kan analyseres helt ned til 10 sekunders presisjon. Det er en klar fordel å velge Logstash som monitoreringsverktøy. Dette fordi loggformatet på hendelser som genereres i OpenStack varierer etter hvilken tjeneste som genererer hendelsen, og ved hjelp av Logstash kan dette tilpasses. Ved å lage skreddersydde filtre kan ønsket informasjon hentes ut og unødvendig informasjon filtreres bort. Nærmere detaljer omkring dette vil bli diskutert i delkapittel 4.3 og 4.4. Verktøyene som er blitt valgt har ikke blitt laget spesielt for å kjøre på en skyplattform, men på grunn av muligheten til å skreddersy verktøyene slik man ønsker, passer de godt til å monitorere OpenStack i henhold til kravene fra UiB. En annen fordel med de valgte verktøyene er at det ikke trengs spesielle protokoller for å hente inn nødvendig data. Dette var en av ulempene med noen av andre verktøyene som ble kartlagt innledningsvis. Dette underbygger at det anbefalte verktøyet Logstash og tilhørende verktøy utgjør en god løsning for monitorering av OpenStack. 4.2 Kartlegging av kritiske og mindre kritiske tjenester Som nevnt i kapittel 1.3 om diskusjon rundt problemstillingene er OpenStack et stort og komplekst rammeverk som består av mange tjenester og komponenter. Siden rammeverket genererer store mengder informasjon om alle hendelser som skjer på systemet vil det fortsatt være utfordringer knyttet til monitoreringen, selv om alle dataene er sentralisert. På bakgrunn av dette er det viktig å se på oppbyggingen av OpenStack for å kartlegge hvilke komponenter som er kritisk og mindre 25

26 kritisk å overvåke. For å kunne kartlegge hvilke tjenester som er kritiske er det først nødvendig å undersøke hvem som skal bruke OpenStack. I skyprosjektet vil dette være brukere i universitets- og høgskolesektoren, og de forskjellige brukerne kan variere fra administrativt ansatte til forskere som er ansatt på midlertidig basis. Den viktigste funksjonaliteten til disse brukerne er å kunne logge inn, opprette, slette, og endre instanser samt å tildele ressurser til seg selv innenfor tillatte grenser. Denne funksjonaliteten vil da være kritisk å overvåke. De tjenestene som da kategoriseres som kritiske er tjenestene som sørger for at normal drift opprettholdes og at brukerne av systemet får utført sitt daglige virke. Dette vil også illustreres i figur i delkapittel 4.4. De kritiske tjenestene vil i dette tilfellet være: «Nova compute» Denne tjenesten muliggjør opprettelse, sletting og endring av instanser. «Nova metadata» Hver computenode har en prosess av metadata-tjenesten kjørende for å gi nye instanser instans-spesifikke data. Dette inkluderer instansidentifikator, tilgjengelighetssone, prioritet, offentlige SSH-nøkler med mer. En bruker vil være avhengig av at denne tjenesten fungerer for å kunne logge på instansen med sin private SSH-nøkkel. «Neutron network» Instansen får tildelt IP-adresse fra DHCP. Instansen kan kommunisere ut i verden og med andre instanser. At nettverket er tilgjengelig muliggjør at brukere får logget inn og brukt instansene sine. «Keystone» OpenStack-tjenestene som fungerer sammen trenger å autentisere gjennom tjenesten Keystone. Informasjon som ikke er feil og advarsler og som ikke har påvirkning på daglig drift anses som mindre kritisk å overvåke. Om disse tjenestene skulle slutte å fungere vil det ikke påvirke brukerne sitt daglige virke, men disse hendelsene må likevel håndteres. Noen eksempler på tjenester som er mindre kritisk å overvåke er: «nova.compute.resource_tracker» Tjeneste som viser oversikt over ledige ressurser til enhver tid. «*.api.openstack.extensions» Tjeneste som viser hvilke tillegg (extensions) som er lastet inn. «nova/neutron/glance/heat/*.service» Tjenester som sier om hovedtjenestene er startet eller stoppet. Det ville vært uhensiktsmessig å legge ved alle tjenestene ettersom den totale listen ville blitt svært lang. Det viktigste er likevel at alle hendelser håndteres ved hjelp av et filter i Logstashkonfigurasjonen. Så om en hendelse ikke skulle bli fanget av et filter vil et samlefilter ta hånd om 26

27 dette og tagge hendelsen som umatchet. For å opprettholde en mest mulig stabil og pålitelig drift er det viktig at tjenester blir tildelt prioritet etter hvor kritiske de er. Dette er viktig i feilsøkingssituasjoner dersom det er en stor andel pågående saker samtidig. Hvis det skulle komme inn en ny sak om en kritisk tjeneste vil denne ha prioritet over andre saker og vil komme fremst i køen basert på prioriteten. Det kan for eksempel settes opp følgende prioriteter: Prioritet: 1a 1b 2a 2b Beskrivelse: Kritisk tjeneste. Påvirker brukers daglige virke og driftsfunksjonalitet. Kritisk tjeneste. Påvirker ikke brukers daglige virke eller driftsfunksjonalitet. Mindre kritisk tjeneste. Kan føre til ytelsesproblemer. Mindre kritisk tjeneste. Fører ikke til ytelsesproblemer. 3 Henvendelser og feil meldt inn av brukere. 4 Generelle spørsmål, forespørsler meldt inn av brukere. 4.3 Filtrering av unyttige data Unyttige data forekommer i OpenStack relativt ofte, og for mange monitoreringssystemer er det blitt et stort problem at unyttig informasjon overskygger den informasjonen som faktisk er viktig. Dette fører på sikt til at monitoreringssystemet blir ubrukelig og ikke kan benyttes etter intensjonen, eller i verste fall ikke blir benyttet i det hele tatt. Om en eller flere tjenester i et monitoreringssystem «går ned» et par ganger om dagen kunne dette føre til unødig bry om tjenesten ikke var kritisk. I Logstash kunne dette blitt enkelt håndtert med et filter, og på denne måten ville ikke den ukritiske tjenesten overskygge eventuelle andre feil som var mer kritisk innen det samme tidsrommet. I Logstash vil det være flere måter å filtrere bort ikke-ønskelig informasjon, og det kommer helt an på dataene hva som er den beste fremgangsmåten. De tre kodeblokkene i vedlegg 2 illustrerer ulike måter informasjon kan håndteres på. Det første filteret filtrerer vekk all logg som er under loggnivå «warning» siden dette i mange tilfeller kan være unyttige data. Om man har lyst til å være mer spesifikk på hva som skal filtreres bort, kan den andre kodeblokken være aktuell. Denne kodeblokken filtrerer kun bort hendelser generert fra spesifikke tjenester, og er en mye bedre fremgangsmåte dersom man ikke ønsker å filtrere vekk for mye informasjon. Den tredje kodeblokken er mer detaljert enn de to førstnevnte. Denne kodeblokken kan brukes dersom en hendelse faller utenfor vanlige filtre og må derfor håndteres med et spesialfilter. Informasjonen i hendelsen kan tagges og senere søkes opp dersom man ønsker å lage statistikk eller visualisere dette i ulike sammenhenger. Om man ønsker å se nærmere på den komplette Logstash-konfigurasjonen som er blitt brukt i forbindelse med datauthentingen i OpenStack, finnes dette i vedlegg 3. I Logstash er det totalt sett svært få begrensninger på hva man kan gjøre når det kommer til filtrering av informasjon. De ulike fremgangsmåtene nevnt ovenfor er bare noen eksempler på hvordan filtreringen av unyttige data kan håndteres. Ved å benytte denne typen filtreringer får man frem den informasjonen som er nødvendig å vite, og unødvendig informasjon blir forkastet. Over tid vil man lære hvilke data som 27

28 er unyttige og hvilke data som er nyttige, og dersom det blir filtrert vekk for mye eller for lite informasjon kan filtrene enkelt justeres for tilpasse dette i fremtiden. Hendelser kan også prosesseres på nytt dersom det skulle være ønskelig. 4.4 Implementering av anbefalt monitoreringsløsning Logstash løser problemene rundt datasentralisering og datauthenting ved å konfigurere alle OpenStack-tjenestene til å logge til linux-syslog. Deretter konfigures syslog til å sende alle loggene videre til maskinen der Logstash kjører. Her blir alle dataene prosessert og ønsket informasjon ekstrahert. Informasjonen blir lagret i Elasticsearch som er en av outputkildene definert i Logstashkonfigurasjonen. Som figur viser blir denne informasjonen visualisert ved hjelp av Kibana, Statsd og Graphite, og disse verktøyene løser problemet rundt datavisualisering. I tillegg blir instansdata i OpenStack visualisert ved hjelp av publiseringsskriptet, og disse dataene hentes direkte fra Ceilometer og sendes til Graphite. Samtidig blir den totale ressursbruken i OpenStack visualisert ved hjelp av dashbordverktøyet Dashing. Med utgangspunkt i dette illustrerer figur hvordan dataflyten i den anbefalte monitoreringsløsningen ser ut. Figur Dataflyt monitoreringsløsning (egenprodusert figur fra Lucidchart) 28

29 Figur Opprettelse av instans i Horizon (Allamaraju, 2013a) Figur viser et flytdiagram for opprettelsen av en instans gjennom webgrensesnittet Horizon. I beste fall vil brukeren få tilbake en kjørende instans uten feil innen kort tid. Andre utfall som kan forekomme er at instansen feiler og blir satt til «state error». Dette kan skje på grunn av tregt eller uresponsivt API, feil eller utilstrekkelige ressurser på nettverk, minnet eller cpu. Videre kan manglende metadata, ressursproblemer og eventuelle andre feil gi «state error». Som vist i dataflyten på figur er det mange tjenester som skal fungere sammen, og en feil på en tjeneste kan også forårsake feil andre steder. Alle feil, hendelser og API-forespørsler i OpenStack logges til fil, og når alle data sendes og sentraliseres til monitoreringsnoden kan dataene håndteres gjennom Logstash (Allamaraju, 2013b). For eksempel gir hendelsen nedenfor følgende informasjon: T23:18:21+00:00 controller 6090 INFO nova.osapi_compute.wsgi.server [req c8-a189-4d c245164c4442 8d496d145b7b4e5fa84e107548f905ad 62e82d58809d4c2da11019dbba2b8f14] "POST /v2/62e82d58809d4c2da11019dbba2b8f14/servers HTTP/1.1" status: 202 len: 737 time: Tidsstempel når hendelsen skjedde: T23:18:21+00:00 2. Hvilken OpenStack-tjener hendelsen kom fra: controller 3. Prosessen til tjenesten som genererte meldingen: Syslog alvorlighetsgrad: INFO 5. OpenStack-tjeneste: nova.osapi_compute.wsgi.server 6. Forespørselsidentifikator: [req c8-a189-4d c245164c4442 8d496d145b7b4e5fa84e107548f905ad 62e82d58809d4c2da11019dbba2b8f14] 7. IP-adresse fra hvor hendelsen ble satt igang: API-forespørsel: "POST /v2/62e82d58809d4c2da11019dbba2b8f14/servers HTTP/1.1" 29

30 9. API-responskode: API-responstid: Meldingen over er en API-forespørsel om å opprette en instans. Den ble utført uten feil med responskoden 202 og hendelsen tok sekunder å utføre. Denne hendelsen og de fleste andre hendelser som oppstår, vil i den anbefalte løsningen for monitorering bli håndtert med Logstash-konfigurasjonen i vedlegg 3. Her vil hele meldingen bli brutt ned og de ulike feltene vil bli lagret og indeksert og kan deretter brukes til å visualisere dataene på flere ulike måter. Som vist i figur kan alle feltene eksempelvis visualiseres til å vise hvor ofte de forekommer gitt i prosent. Figur Kibana visualisering (egenprodusert figur fra Kibana) Videre kan alle de ulike loggnivåene og tjenestene som genererer dem telles opp. Dette kan også gjøres med API-responskodene og API-responstidene, som vist i figur Figur Nova Dashbord (egenprodusert figur fra Kibana) Hvor mange hendelser som forekommer og hva de viser avhenger av søkekriteriet. Hvis søkekriteriet endres vil også de ulike grafene endre seg etter resultatet. Samme informasjon som vist i figurene over kan også visualiseres ved hjelp av grafer. Alle OpenStack API-forespørsler blir utført med hensyn på tid og ved å grafe dette kan man se utvikling av data over tid. Hvis det for eksempel skulle være en dag det er liten kapasitet på systemet, vil dette gjøre utslag i grafen. Figur illustrerer at Neutron API-responstiden kom til en peak like etter da responstiden økte til nesten 0.08 sekunder. Den mest sannsynlige forklaringen i dette tilfellet er at en API-forespørsel tok lengre tid enn de øvrige forespørslene, og dette ga et utslag. 30

31 Figur Neutron API-respons (egenprodusert figur fra Grafana) Under arbeidet med bacheloroppgaven har det totalt blitt generert 9,202,850 millioner logghendelser som har blitt håndtert av Logstash. Den kjappeste API-forespørselen som har forekommet har vært sekunder og den høyeste har vært sekunder. Den anbefalte løsningen for monitorering ligger offentlig på Github under kodenavnet «winch» 2, som er en del av skyprosjektets testplattform for OpenStack-rammeverket. Videre har alt av arbeid, refleksjoner og problemer underveis blitt publisert offentlig under UiBs bloggrammeverk Monitorering ved hjelp av Logstash hos andre aktører For å underbygge Logstash som anbefalt verktøy monitorering av OpenStack har det under arbeidet med bacheloroppgaven også vært interessant å kikke på andre aktører som bruker dette som som en del av sin monitoreringsløsning. Dette fordi et av kravene for verktøyutvelgelsen slo fast at verktøyene skulle være i bruk av store aktører slik at man kunne hente erfaringer og hjelp dersom problemer skulle oppstå. I denne sammenheng har jeg valgt å se nærmere på tre store aktører Ebay OpenStack hos Ebay startet som en sky for utviklere sommeren Når en feil skjedde innad i skyen var det en enkel jobb å logge inn på de forskjellige tjenerne og feilsøke hva som hadde skjedd. De senere årene har OpenStack hos Ebay vokst til å bli en sky som inneholder flere tusen maskiner og feilsøking ble derfor mye mer komplisert enn før. Dette førte til at Ebay hadde behov for et monitoreringssystem og i denne forbindelse startet de med å monitorere OpenStack ved hjelp av verktøyene Logstash, Elasticsearch og Kibana. Videre ble disse verktøyene satt i kombinasjon med Statsd, Graphite og Zabbix for å visualisere informasjon, og for å lage alarmer og notifikasjoner. I tillegg blir det grafet responskoder og responstider fra de ulike OpenStack-tjenestene, samt at de benytter grok-filtre for ekstrahering av relevant informasjon. Totalt prosesserer Ebay flere terrabyte med loggdata i måneden noe som viser at Logstash er verdt å satse på (openstack.org, 2013)