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!

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.

 

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.

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

Dag 2: OpenStack from scratch

7. august gikk med til å utføre en OpenStack installasjon fra scratch. Denne installasjonen gir et godt inntrykk av hva komponenter OpenStack består av og hvordan disse skal fungere sammen i en komplett installasjon.

Vi støtte på litt problemer etter installasjonen av OpenStack from scratch. Noe av hovedfunksjonaliteten i systemet er å kunne lage og bygge instanser av maskiner som skal kjøre i et driftsmiljø. Denne biten feilet og vi har startet feilsøking av hva som kan ha gått galt. Dette er noe vi kommer til å fortsette med i morgen.

OpenStack from scratch er et github prosjekt som er blitt laget i forbindelse med prosjektet jeg er med i på UIB.  Hele prosjektet ligger åpent på github -> https://github.com/norcams/ofs

Før jeg begynner å gå inn i detaljer om OpenStack, vil det være greit for leserne å vite litt om bakgrunnen til programvaren og hva den brukes til. Velger i denne sammenhengen å vise til Wikipedia artikkelen som jeg syns har oppsummert dette ganske bra, samt at den forklarer bruken til hver av komponentene.

OpenStack