Category: openstack

Publisert

Dag 11: Generering av testgrafer

Noe mer konfigurasjon måtte til for at den nye grafnoden skulle fungere som den skulle. Provisjonering av noden måtte kjøres to ganger, i tillegg til at en rekke småting måtte konfigureres manuelt. Med alle disse hindringene til side var det tid for å generere noen grafer.

Ved hjelp av et script som heter ceilometer publisher har jeg hatt mulighet til å pushe enkelte data direkte fra ceilometer og inn til Graphite. Data som cpu- og minnebruk har vært de to mest aktuelle, og ved å opprette instanser i OpenStack har jeg kunne sett at grafene utvikler seg over tid. Dette gir et interessant overblikk over tilgjengelige ressurser på systemet og hjelper oss å se data i sammenheng. Samtidig som det også tilbyr systemadministratorer proaktiv overvåkning ved å kunne forutse og hindre problemer før de oppstår.

Når man skal sette opp grafer i Graphite/Grafana baserer man seg på såkalte metrics. Hvis man for eksempel ønsker å se på CPU bruk på en maskin het metric’en i vårt tilfelle: carbon.agents.graphite_winch_local-a.cpuUsage. Denne visualiseres slik:

cpu-bruk

Publisert

Dag 5: Start av fysisk testmiljø

Som tidligere publisert på bloggen har jeg fått tildelt en 32GB fysisk blade server der winch har blitt installert. Hensikten med dette er å kjøre et virtuelt OpenStack-testmiljø der jeg kan teste ulike monitoreringssystem. For øyeblikket er jeg i gang med å teste Logstash, Elasticsearch og Kibana og har satt opp dette i winch under en egen monitoreringsbranch. I denne branchen har jeg laget en logstash node som er konfigurert til å ta imot alle loggdata som kommer fra OpenStack.

Her vil jeg ha muligheten til å se hvilke data som kommer inn slik at jeg kan hente ut den informasjonen som er relevant. Samtidig ønsker jeg å kunne filtrere vekk all unyttig informasjon slik at dette ikke overskygger viktige data. Jeg har laget en vagrantboks som installerer Logstash automatisk ved hjelp av puppet. Dersom noe feil skulle skje eller testoppsettet ikke skulle fungere som det skal, kan jeg enkelt slette og starte maskinen på nytt for å komme tilbake til der jeg var før feilen skjedde. Ved hjelp av dette sparer jeg mye tid og kan fokusere mer på testingen av de ulike verktøyene. Vagrantboksen er definert slik.

Publisert

Dag 3: Submoduler i git og installasjon på blade server

I forrige uke fikk jeg problemer med å legge til enkelte puppetmoduler til monitoreringsbranchen på github. Etter en del feilsøking endte jeg  opp med å legge disse til som submoduler. Fordelen med submoduler er at man slipper å måtte oppdatere modulene i sitt eget repository. Ved å kjøre kommandoen nedenfor vil modulen lastes ned, og det vil ligge en sti til det remote repositoriet i .gitmodules.

git submodule add https://github.com/elastic/puppet-logstash

I tillegg til submodulene er det også blitt lagt til en egen mappe for alle konfigurasjonsfiler og patterns til logstash. Rsyslog.conf ligger også her, men planen videre er å legge til rsyslog puppetmodulen slik at det aller meste kan styres gjennom puppet. Jeg begynte også å installere winch på blade serveren jeg har fått tildelt. Denne serveren har 32GB med minne og jeg har derfor mulighet til å ha kjørende en god del instanser som jeg skal teste med. Mer om dette i morgen!

Publisert

Dag 2: Integrering av logstash i «winch»

Under utplasseringen var jeg med på å lage et automatisk oppsett som installerte OpenStack og tilhørende komponenter. Dette ble gjort ufifra et prosjekt på github som het winch. Som jeg tok opp i min forrige bloggpost ønsker jeg å samle alle OpenStack loggene på en og samme maskin. Derfor her jeg laget en ny branch i winch som inkluderer en monitoreringsnode. Denne noden vil være ansvarlig for alt som skjer med tanke på logginnsamling, parsing og visualisering av informasjon. Da er det viktig at verktøyene som skal gjøre dette blir installert på samme måte som tidligere, ved hjelp av puppetmoduler.  Da kan vi sette en ønsket tilstand og si at den nye noden skal være en monitoreringsnode.

Arbeidet med å puppetifisere alle verktøyene er kommet godt i gang. Har laget en manifest fil for logstash som kan sees her. Denne vil benytte seg av puppet modulene lokalisert i puppet/modules og installere verktøyene med konfigurasjonsfiler spesifisert i manifestet. Det som gjenstår for at integreringen skal være komplett er å legge til de puppetmodulene jeg trenger. Disse er submoduler og blir derfor lagt til annerledes. Mer om dette i neste bloggpost.

Publisert

Dag 0: Oppsummering

Denne bloggposten er en oppsummering av arbeidet som har blitt gjort før forprosjektet i bacheloroppgaven har kommet i gang.

I henhold til problemstillingen skal jeg «kartlegge forskjellige monitoreringsverktøy og teste bruken av disse». Dette er arbeid som jeg har kommet godt i gang og jeg har fått tilegnet med rimelig god oversikt over forskjellige verktøy som eksisterer for bruk i OpenStack per i dag. Videre skal jeg også «belyse fordeler og ulemper med forskjellige overvåkningsverktøy. Hva passer best til vårt bruk? Er noen verktøy bedre for sky enn for tradisjonell bruk?»
Så langt kan jeg se klare fordeler med enkelte verktøy som jeg linket til tidligere. Verktøene er godt vedlikeholdte, populære og de er alle av åpen kildekode. Sistnevnte punkt tillater meg i aller største grad å spesialtilpasse verktøyene til mitt formål. Jeg har muligheten til å få ut den informasjonen som er av relevans for å kunne identifisere og løse problemer som oppstår. I tillegg til at jeg veldig enkelt kan tagge informasjon som ikke er av relevans som unødvendig slik at dette ikke overskygger faktiske problemer som eventuelt kan forekomme.

Dette har gjort jobben med å finne et verktøy som passer problembeskrivelsen noe enklere. Det er ikke alle verktøy en vil ha mulighet til å spesialtilpasse i så stor grad, og disse verktøyene vil naturligvis bli valgt bort.

Jeg også fått tildelt en egen blade server der uttestingen av forskjellige monitoreringsverktøy skal foregå. Blade serveren har betydelige ressurser som er i stand til å simulere et OpenStack miljø i mye større grad enn det arbeidsstasjonen min til nå har hatt mulighet for. Dette gjør testingen av potensielle verktøy enklere i tillegg til at dataene jeg kommer til å teste med blir mest mulig reelle.

 

2015-02-24 13.13.52

2015-02-24 13.13.37

 

Publisert

Dag 30: Monitorering av OpenStack ved hjelp av Icinga

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.

Publisert

Dag 29: En bloggpost om oppetid og maskinvare og sånn…

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.

uptime

Publisert

Dag 25 & 26: Samstemt provisjonering av ceph maskiner

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/

Publisert

Dag 23: Installering av Ceph kluster med hjelp av puppet-moduler

Det manuelle oppsettet av ceph-klusteret som ble installert forrige gang fungerte bra. Planen for i dag var å lage et lignende kluster ved hjelp av puppet moduler.

Som vi husker fra tegningen jeg publiserte i forrige innlegg, fantes det en egen monitoreringsnode og x antall osd noder. Ceph klusteret blir spredt over alle osd nodene. Mens det er en monitoreringsnode som holder styr på klusteret og hvor mange noder som er med osv.  For å hindre SPOF har vi i et produksjonsmiljø lyst å kjøre flere monitoreringsnoder samtidig. I tillegg ønsker vi å kjøre monitoreringsnoder og osd noder på samme maskin. Dette for å minske behovet for ekstra maskiner.

I node definisjonen i vagrant har vi lagt til 3 ceph noder; ceph01, ceph02 og ceph03. Innstillinger for de 3 maskinene har blitt satt i common.yaml filen slik at vi kan provisjonere med puppet. Innstillingene til ceph inneholder alt fra passord, medlemmer  på klusteret, størrelsen til klusteret og hvor klusteret skal være på de medlemmene som er definert. Dette vil nå bli satt opp automatisk for oss når vi installerer ceph nodene.

Etter dette kunne vi starte opp maskinene på samme måte som vi har gjort tidligere. Klusteret innstalleres når maskinen kommer opp for første gang. Mer om ceph neste gang.