Monitorering av OpenStack ved UiB
Siste dag på UiB i utplasseringsfaget hadde skyinfrastrukturen kommet på plass i lageret. Dette er bare første del av to leveranser, men det er på dette utstyret at skyen skal installeres.
Det blir spennende tider fremover!
http://delldirekte.no/banebrytende-akademisk-skyprosjekt/
Fortsatte på dokumentasjonen av winch og hvordan man kan installere OpenStack ved hjelp av manager noden og Foreman. Forøvrig kan alt av dokumentasjonen rundt prosjektet leses på readthedocs.
I tillegg har jeg fått en konkret oppgave over jul til å kikke på OpenStack monasca. Monasca er et åpent kildekodeverktøy som går under prinsippet monitoring-as-a-service som overvåker OpenStack. Stort verktøy som skal bli interessant å se på og installere. Dette blir også et av monitoreringsverktøyene som jeg skal kikke på i forbindelse med bachelorprosjektet neste år. Her er en liten oversikt over hvordan Monasca integreres med OpenStack:
Benyttet mesteparten av dagen til å kikke på to verktøy som heter Logstash og Kibana. Logstash er et verktøy for å samle og håndtere logg. Den samler inn, parser og lagrer logg og viser dem i et webpanel kalt Kibana. Her kan man ved hjelp av et kraftig søkeverktøy søke opp alt av hendelser som har skjedd på systemet siden loggingen startet. I webpanelet vil det genereres grafer på hvor ofte en hendelse man har søkt på forekommer. Ganske nyttig dersom man skal filtrere en spesifikk feil for å finne ut om feilen er kritisk eller ikke.
Konfigurasjonsmessig kan man gjøre mye med logstash. Det viktigste av konfigurasjonen skjer ved hjelp av en konfigurasjonsfil der en spesifiserer input, hva som skal filtreres og output. Output delen kan være forskjellige tjenester, i dette tilfellet ble output satt til å være elasticsearch. Elasticsearch er logstash’ sin backend for lagring av logg. Senere vil jeg ta for meg installasjonen og oppsett av logstash og kartlegge tjenester som skal overvåkes. I tillegg ønsker jeg også å kikke nærmere på verktøyet Graphite som kan spesifiseres som output.
Monitorering er et stort og viktig tema innenfor OpenStack og det finnes mange forskjellige verktøy som kan benyttes. Jeg har så vidt begynt å kikke på Icinga.
Icinga kan vise seg å være et nyttig verktøy for monitorering av OpenStack. Verktøyet er i utgangspunktet basert på Nagios, derfor kan mange av tilleggene som var skrevet for Nagios brukes direkte i Icinga. For eksempel har Stackforge en rekke scripts som kan brukes for å overvåke rene OpenStack tjenester.
Samtidig har utviklerne bak Icinga støtte for å installere verktøyet ved hjelp av puppet moduler, og tilbyr også vagrant bokser til testformål. Siden resten av IaaS plattformen gjør dette per dags dato er Icinga absolutt interessant å ha med videre som et aktuelt verktøy.
Dagene til den forrige kontor PC’en min var talte. 8GB just won’t cut it når man skal kjøre sky. Hver av maskinene i OpenStack rammeverket ble definert med 2GB RAM, og ville en ha mer enn 4 maskiner ble det fort lite minne igjen. Fikk dermed ny arbeidsstasjon som hadde 16GB med RAM, og provisjonering av OpenStack maskiner gikk nå unna fort som fy.
Vi husker alle den første dagen og maskinen som lå på hylla. Helt til maskinen ble byttet ut hadde den siste tilgjengelige programvare, den ble aldri startet om, og den fungerte utmerket i det aller fleste tilfeller. Nå skal maskinen få nytt liv hjemme, og forhåpentligvis får den et eget kabinett.
Dette semesteret har gitt meg god innsikt i OpenStack og de forskjellige komponentene rammeverket består av. Siden jeg skal skrive bacheloroppgaven min til neste år har jeg i denne sammenhengen fått lov til å skrive den her ved UIB.
Jeg arbeider for tiden med prosjektbeskrivelse til bachelorprosjektet. Innledning, teori og metode er deler som foreløpig er ferdig i prosjektbeskrivelsen, mens det fortsatt gjenstår noen deler på problemstillingen. Jeg ønsker å ha en problemstilling som går ut på monitorering av OpenStack. Dette er et stort og viktig tema der jeg har muligheten til å gå i dybden av komponentene og finne ut hva tjenester som er kritiske å overvåke kontra tjenester som ikke er det.
Jeg vil ha mulighet til å teste ulike monitoreringsverktøy og kartlegge bruken av disse. Det vil være nyttig å finne ut av fordeler og ulemper med enkelte verktøy og gjøre en vurdering på hvilke verktøy som vil være hensiktsmessig å bruke i skysammenheng. I tillegg vil jeg også se på eventuelle etiske spørsmål og personvernspørsmål i forbindelse med overvåkning av OpenStack.
Fullført prosjektbeskrivelse vil bli publisert her på bloggen når den er klar.
Mesteparten av dagen ble benyttet til å lese over dokumentasjonen til «winch». Jeg har fått i oppgave å oppdatere dokumentasjonen slik at den kan brukes til slik som «winch» er nå.
I dette arbeidet kommer jeg til å bruke et verktøy som heter ReText. Dette er et tekstredigeringsverktøy som gir direkte preview i programmet for hvordan teksten du redigerer vil bli seende ut. I motsening til andre editorer der en er tvunget av å måtte åpne siden i en nettleser for å se hvordan den ser ut.
Dokumentasjonen finnes på http://winch.readthedocs.org/, flere oppdateringer vil skje de påfølgende ukene.
Fra forrige gang fant jeg ut at et Ceph kluster ikke kan provisjoneres node for node. Dette ble også bekreftet av en av utviklerne fra Stackforge. På bakgrunn av dette laget jeg et script som tar opp alle nodene samtidig. I tillegg ble det lagt inn en 10 sekunders forsinkelse mellom hver av maskinene slik at vi får korrekt IP adresse på dem. Scriptet er et veldig enkelt script som kan sees i sin helhet på Github.
Nå vil ikke timeout feilen fra forrige innlegg skje. Når den kommer til punktet der nøklene skal sendes over til de andre maskinene i ceph klusteret vil de andre nodene også ha kommet til dette steget. På denne måten klarer nøklene å spres over til de andre maskinene og provisjoneringen med puppet går gjennom uten feil.
Videre arbeid blir nå å integrere ceph med resten av OpenStack slik at instansene vi oppretter bruker ceph som lagringsområde. I tillegg skal jeg skrive en del dokumentasjon om winch og hvordan man tar det bedre i bruk. Foreløpig dokumentasjon kan sees på http://winch.readthedocs.org/en/latest/
Ved opprettelse av første monitoreringsnode, ceph01 feiler kjøringen av puppet modulene. Fra det manuelle oppsettet lærte vi at den første noden setter inn nøkler og passord på de andre nodene i klusteret.
Error: /Stage[main]/Ceph::Profile::Mon/Ceph::Key[client.bootstrap-osd]/Exec[ceph-injectkey-client.bootstrap-osd]/
Når de to andre nodene ceph02 og ceph03 blir provisjonert så skjer ikke denne feilen. Ting kan tyde på at nodene er svært avhenige av hverandre når de skal provisjoneres. Ceph01 kan deretter provisjoneres på nytt etter at andre og tredje node er kommet på. Da fungerer det uten problemer og vi kan se utifra ceph -status at vi har et aktivt og kjørende kluster.
cluster 4b5c8c0a-ff60-454b-a1b4-9747aa737d19
health HEALTH_WARN clock skew detected on mon.ceph02, mon.ceph03
monmap e2: 3 mons at {ceph01=172.16.33.13:6789/0,ceph02=172.16.33.14:6789/0,ceph03=172.16.33.15:6789/0}, election epoch 6, quorum 0,1,2 ceph01,ceph02,ceph03
osdmap e17: 6 osds: 6 up, 6 in
pgmap v24: 192 pgs, 3 pools, 0 bytes data, 0 objects
68720 MB used, 149 GB / 227 GB avail
192 active+clean