Category: winch

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 4: Videre konfigurasjon av winch

Dagen ble benyttet til å teste at provisjoneringen av controller og compute fungerer sammen med logstash. Det er mye av konfigurasjonen som utføres manuelt for øyeblikket. Blant annet må alle OpenStack tjenestene manuelt endres for at de skal logge til syslog og sende til logstash noden som tar imot og parser loggende.

Førsteprioritet er uansett å få opp et fysisk testmiljø der jeg har muligheten til å starte flere instanser og sjekke at all informasjon som blir generert i loggfilene blir samlet og håndtert. Videre må nøkkelfunksjonalitet i systemet testes på en slik måte at loggdataene som blir generert kan si noe om hvilken tilstand systemet er i. Om tjenester er oppe og går, om det har forekommet feil den siste tiden osv.

Publisert

Dag 32: Dokumentasjon og OpenStack Monasca

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:

Monasca-arch-component-diagram

Publisert

Dag 27: Oppdatering av «winch» dokumentasjon

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.

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 24: Feil med opprettelse av første monitoreringsnode

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

 

 

Publisert

Dag 19: Persistent montering av /vagrant/ mappe og netforward

Som tidligere nevnt har det vært problemer ved bruk av vagrant at vi mister /vagrant mappen på manager maskinen. I denne mappen ligger det en del script for å installere og konfigurere Foreman og puppet. Da er det veldig viktig at montering av denne mappen fungerer i alle tilfeller der vi trenger den.

Ved bruk av vagrant har dette vist seg å være vanskelig. Etter en oppdatering av maskinen eller en restart utenfor vagrant miljøet blir man tvunget til å kjøre kompilering av virtualbox addons og kjernemoduler for å få monteringen opp igjen. Dette krever mye manuelt arbeid og det ville vært lettere å automatisert prosessen. Derfor har jeg laget et script som ordner dette. I tillegg til å montere mappen kjører den også netforward på manager maskinen. Denne har tidligere falt ut når manager har blitt startet om utenfor vagrant og er kritisk for at Foreman fungerer slik vi vil.

Scriptet kan sees i sin helhet på github.

Publisert

Dag 17: Installasjon av compute og controller node ved hjelp av Foreman

Vi fortsatte med feilsøkingen fra fredag om hvorfor puppet modulene fra «winch» ikke ville fungere når vi provisjonerte med Foreman. De hadde virket før og det ga lite mening at de ikke skulle virke nå som Foreman var med i bildet.

Det viste seg at feilen lå spredt i flere konfigurasjonsfiler, og dette gjorde at puppet modulene feilet på maskinene som Foreman installerte. Nå har det blitt gjort endringer i kickstart filene til Foreman for å gjøre at dette problemet ikke vil oppstå igjen. Nå var det mulig å installere både controller og compute noder ved hjelp av Foreman der alle puppet modulene blir installert.

Til nå har vi brukt vagrant og virtualbox for å lage og provisjonere maskiner. Vagrant legger opp et eth0 interface med en NAT adresse, men dette kludrer mye til det nettverksoppsettet vi ønsker. Derfor er neste steg nå å lage install script som kan lage og sette opp virtualbox maskiner for å unngå at eth0 inferfacet blir bundet opp til denne NAT adressen. Mer om dette på fredag.

Publisert

Dag 14: Oppdatering av Foreman og installasjon av compute noder

Vi startet dagen med å feilsøke på hvorfor TFTP serveren til Foreman ikke ville fungere. Flere problemer oppstod med versjon 1.4.5 uten at vi fant noen gode forklaringer på hvorfor. Maskinen som Foreman er installert på kjører en DHCP server og en TFTP server. Disse tjenestene brukes når Foreman skal provisjonere opp maskiner. Da blir maskinene PXE bootet og den henter ned det aktuelle operativsystemet til maskinen og dette installeres automatisk.

Når en eldre pakke byr på problemer som ovenfor er løsningen som oftest å oppdatere til nyeste versjon. Alle installeringsscriptene til Foreman ble derfor modifisert slik at scriptet henter den nyeste programvaren fra repositoriet. Etter at Foreman hadde komt opp til versjon 1.6 fungerte TFTP serveren og det var nå mulig å provisjonere opp maskiner. Dette ble testet både på en fysisk maskin og på en virtuell maskin.

Når man skal provisjonere opp en maskin kan man velge fra en haug med templater på hva innstillinger man ønsker osv. Foreman tilbyr mye funskjonalitet og det er et stort verktøy å sette seg inn i. Heldigvis er dette noe vi skal holde på med en god stund fremover, og det alltid kjekt med bratte læringskurver.

Eksempelutdrag på et Foreman dashboard hentet fra google:

foreman

 

Publisert

Dag 13: Installasjon av The Foreman

Etter å ha fått «winch» oppgradert til siste OpenStack versjon; Icehouse started vi med installasjonen av The Foreman. Foreman ligger inne i «winch» med versjon 1.4.5 og formålet med å installere denne versjonen er å kunne verifisere at funksjonaliteten fungerer slik vi vil. Senere vil Foreman bli oppgradert til versjon 1.6.0 .

Foreman vil være en egen komponent i vår OpenStack installasjon og den kjører derfor på en egen maskin, nemlig manager. Før installasjon av Foreman må denne maskinen ha blitt laget. Inne i vagrant mappen på winch finnes det et script som heter foreman.sh. Det er dette scriptet som kjøres når Foreman installeres.

Etter installasjon skjer alt av administrasjon inne fra et webpanel. Her kan man sette opp puppet moduler, templater for installasjon og provisjonering, diskoppsett med mer. Det finnes mange muligheter, og det er dette verktøyet vi skal bruke i lag med OpenStack. Eksempelvis om man skulle installere 40 servere ville man konfigurert Foreman til å gjøre dette på en rask og effektiv måte. Alternativt måtte man gjort dette for hver og enkelt server noe som ikke skalerer i lengden. På mandag vil vi jobbe videre med The Foreman og sette igang med provisjonering av compute noder.