Author: ksk037

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 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 22: Installering av Ceph kluster

Agenda i dag var å få lest litt mer om filsystemet Ceph. Ceph er et objekt basert filsystem som replikerer sine data over et lagringskluster. Det tar vekk behovet for et tradisjonelt SAN. Filsystemet ble utviklet i 2007, og ble i Mai i år kjøpt opp av RedHat.

I prosjektet har vi lyst å deployere Ceph ved bruk av Puppet moduler. For å få en så knirkefri installasjon som overhodet mulig kommer vi til å bruke samme utviklere som laget OpenStack puppet modulene vi benyttet tidligere. Stackforge utviklerne har mye spennende GitHub prosjekter innenfor OpenStack og dens komponenter. For de som er interessert i å sjekke ut Ceph repositoriet kan ta en kikk her.

I første omgang har vi deployert et Ceph kluster manuelt for å få et innblikk i hvordan dette fungerer bit for bit før vi begynner å bruke puppet modulene. Det er mye god dokumentasjon som ligger ute på hjemmesidene til Ceph, vi begynte med følgende «quick-start-preflight».  Deretter ble klusteret installert ved å følge «quick-start-deploy».

Et kjørende kluster can for eksempel se slik ut:

ceph-cluster

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

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