Category: winch

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 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.

 

Publisert

Dag 20 & 21: Testing av Openstack deployment fra «winch»

I den siste tiden har det skjedd flere endringer på «winch» prosjektet på Github. Vi har nå et automatisert testmiljø som kan installere OpenStack og alle dens komponenter uten å måtte sette mange innstillinger manuelt.  Dette gir oss stort spillerom dersom noe ikke skulle virke med senere anledninger. Da kan vi slette en komponent og installere den på nytt igjen uten å tape mye tid.

Samtidig vil det være lettere å lære seg de ulike OpenStack komponentene når man kan se hvordan de fungerer sammen i praksis. Det er  lett å miste oversikten når man begynner med rammeverket siden det virker veldig overveldende og detaljert i starten.

Dagens arbeid innebærte en god del testing, samt en endring i en av installasjonsfilene. Vi kan nå konkludere med at «winch» er brukbart i forhold til de tingene vi skal gjøre videre. Blant annet skal vi kikke nærmere på storage, rettere sagt Ceph.

 

 

Publisert

Dag 18: Oppretting av virtualbox maskiner uten vagrant

Onsdag 1. oktober var offisiel kickoff for UH-Sky prosjektet som jeg er en del av. Fremover vil det være mye større aktivitet på github i form av endringer enn tidligere. Til nå har arbeidet med «winch» vært preget av mye feilsøking og manuell konfigurasjon. Det vi ønsker å oppnå er å lage et helautomatisk oppsett for å deployere OpenStack i et testmiljø.

For å unngå en del problemer vi har opplevd tidligere har vi besluttet å lage et script som oppretter virtualbox maskiner uten innblanding fra vagrant. Vagrant låser blant annet eth0 interfacet og setter dette til et NAT’et interface. Dette har ført til at maskiner ikke får TFTP bootet når skal provisjonere disse med Foreman. I tillegg har vi fått en del linux bro problematikk og det har krevd mye feilsøking for å få ting til å fungere som de skal. For nå har jeg laget et script som vil opprette de to komponentene compute og controller. Senere vil vi nok også utvide scriptet til å gjelde for storage og network også.