Tag: openstack

Publisert

Dag 25-29: Oppsett av dashing-ceph/openstack, rydding av config

Den siste uken har gått med til å sette opp dashing-ceph, dashing-openstack, rydding av Logstash config og oppdatering av bacheloroppgaven. Dashing er kort fortalt et dashbord rammeverk for å visualisere informasjon i «fine bokser», se bilde nedenfor. Det er mye ting i luften akkurat nå og det kommer til å bli en hektisk tid fremover mot innleveringen andre uken i juni.

dashing-ceph

Bachelorprosjektet skal framføres enten den 10, 11 eller 15 juni og alle som er interessert må komme å høre på! Planen er å ha en enkel men oversiktlig presentasjon med live demo som viser hva jeg har jobbet med dette semesteret. I uken som kommer vil de siste tekniske bitene bli implementert før skriveperioden starter for fullt.

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 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 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 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 15 & 16: Testing og oppsett av Dell s4810 switcher og feilsøking av puppet moduler

Mandagen ble brukt til å konfigurere opp to nye Dell s4810 switcher som skal brukes til testformål i prosjektet. I motsetning til andre switcher som typisk kjører sitt eget operativsystem kjører disse switchene på Linux. Cumulus Linux er en variant av Debian og det er slike switcher som skal benyttes når den endelige skyplattformen installeres. Oppsettet vi laget og monterte i rack kan visualiseres på denne måten:

iaas ruting-redundans test - Network general-1

I tillegg har vi også jobbet videre med Foreman. Det er en del problemer som gjenstår før vi kan fullprovisjonere maskiner ved hjelp av puppet moduler. Etter at Foreman har provisjonert en maskin sliter vi med å få puppet modulene til å virke på maskinen. Fra tidligere fungerte modulene etter vi hadde oppdatert dem i forbindelse med «winch» prosjektet. Eneste endringen nå er at vi bruker Foreman. Videre feilsøking på mandag…

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.

 

Publisert

Dag 12: Feilsøking av «winch» installasjon

Fra tidligere har vi ofte hatt problemer med å få instanser til å snakke med verden på utsiden. Dette har ofte krevd mer konfigurasjon og feilsøking enn først antatt. Denne gangen var intet unntak. Det ble mye repetering av OpenStack network in too much detail og sjekking av brannmurregler for å verifisere at alt var i orden.

Etter en god del feilsøking viste det seg til slutt å være at feilen oppstod på grunn av vagrant. Vi bruker vagrant til å lage virtuelle maskiner og denne hadde da stokket om på IP adressene til de forskjellige interfacene maskinene skulle ha. Derfor var det mye som ikke ble riktig og etterpå kunne maskinene komme på nett. Senere i uken ble også «winch» prosjektet oppdatert. Endringer kan sees her.