Dag 8: Videre feilsøking av neutron-server

På denne dagen gikk mye av tiden med til å feilsøke hvorfor neutron-server ikke ville starte på compute noden. Feilsøking uten å ha noe logg å lese kan ofte være vanskelig, og da kommer det helt an på hvilke svar man kan finne på nettet i lignende installasjoner. Til slutt viste det seg at en av de tilleggene som neutron bruker ikke fantes på den stien den skulle ha vært, og tillegget var heller ikke installert.

yum install openstack-neutron-ml2

I tillegg skal det være en plugin.ini fil under /etc/neutron/ som skal holde rede på hvilke tillegg man har lagt til installasjonen av OpenStack. Denne må symlinkes hertil.

ln -s /etc/neutron/plugins/ml2/ml2_conf.ini /etc/neutron/plugin.ini

Etter dette fungerte det å starte neutron-server tjenesten. Foruten om dette har det vært noen stabilitetsproblemer på controller noden. Denne har til nå kjørt på en virtuell maskin og har flere ganger fått økt minnetildeling. I skrivende stund kjører den på 4GB RAM, halvparten av det jeg har på min arbeidsstasjon. Jeg har opptil flere ganger hatt stabilitetsproblemer ved å kjøre denne maskinen virtuelt. En del ganger har jeg blitt nødt til å kjøre power down eller reset for å få kontakt med maskinen. På grunn av dette er planen til neste gang å få lagt controller noden over på en fysisk maskin. Samtidig skal vi også installere ML2 tillegget før vi kjører packstack, slik at vi ikke får de samme problemene med neutron-server som tidligere.

 

 

Dag 7: OpenStack networking in too much detail & feilsøking av neutron-server

Etter at en virtuell maskin har blitt startet i en instans er vi interessert i å kunne snakke med denne maskinen utenfra OpenStack nettverket. Det er her OpenStack in to much detail kommer inn i bildet.  Se bildet nedenfor for mer detaljer.

Neutron_architecture

Jeg vil ikke prøve å forklare dette i detalj da nettverket er veldig komplekst. Artikkelen tar utgangspunkt i å forklare arkitekturen, og hvordan nettverk, bruer og tunneler henger sammen i en OpenStack installasjon. Bildet er forøvrig skrevet ut og ligger ved arbeidsstasjonen min, regner med at det skal repeteres en god del ganger før nettverket sitter 100%.

Etter at vi hadde fått laget instanser ville ikke nettverket i en instans starte slik vi ville. Etter litt feilsøking fant vi ut at neutron-server tjenesten på compute noden ikke starter. Tjenesten dør momentant når den blir startet og det skjer såpass fort at det ikke er noe innslag i loggen som kan si hva som er galt. Resten av dagen gikk med til å feilsøke hvorfor neutron-server ikke ville starte. Initscriptet er likt som på controller noden, og /etc/neutron/neutron.conf er identisk på de to maskinene. Dette må feilsøkes ytterligere, fortsettelse følger på mandag.

Dag 6: Installering av fysisk compute node

18. august hadde vi fått installert compute noden på en fysisk maskin. Til nå hadde vi hatt problemer med å lage og starte instanser når alt kjørte på en node, på grunn av lite tilgjengelige ressurser. Som tidligere forklart kunne vi nå bruke packstack svarfilen som ville gjøre installsjonen for oss. Det eneste man oppgir er root passordet til maskinen man skal installere på.

**** Installation completed successfully ******

Etter installasjonen får man oppgitt adressen til Horizon der man kan logge inn og administrere skyen. På dette tidspunktet klarte vi å logge inn og lage instanser.

lage-instans

Det er de tilgjengelige ressursene man har på compute noden som vil sette begrensninger på hvor mange instanser man kan lage. Man kan velge størrelse på maskinen og hvor mange instanser av maskinen som skal starte. Utifra de verdiene man spesifiserer vil ressursene under project limits endre seg. I verktøyet kan man spesifisere sikkerhet, hva nettverk maskinen skal ha, hva post-scripts som skal kjøres og om man vil kjøre automatisk eller manuelt diskoppsett. Alt i alt er det et veldig oversiktlig og funksjonelt verktøy som det skal bli veldig kjekt å lære mer om!

 

Dag 5: Prøving og feiling med packstack –allinone

15 august. De tre hovedkomponentene til OpenStack hadde nå blitt installert med packstack til å kjøre på en og samme node.  Dette burde ikke by på store problemer da RDO pakken fra Red Hat er godt testet og fungerer i mange installasjoner av OpenStack der ute i dag.

Alle instanser som kjører innad i OpenStack rammeverket kan administreres via et webpanel kalt Horizon. Panelet gir en god oversikt over antall instanser, deres ressursbruk, last, og annen info. På sikt skal både administratorer og vanlige brukere kunne logge seg inn her og administrere sine egne maskiner til forskjellige formål. Et lite utdrag fra Horizon:

Horizon-overview

Vi fikk fortsatt problemer med å lage og starte instanser med å kjøre de tre hovedkomponentene på en og samme node. Mistenker at dette kan ha med lite tilgjengelige ressurser siden vi kjører på en virtuell maskin gjennom VirtualBox. For å løse denne problematikken ble svaret å lage en ekstra compute node på en fysisk maskin. Med dette ville vi unngå problematikken vi hadde hatt til nå, i tillegg til at vi kan lage flere maskiner siden vi har mer ressurser tilgjengelig.

For å installere en egen compute node trenger man, (i vårt tilfelle) en nyinstallert CentOS samt packstack-answer filen vi brukte når vi installerte hoved noden. Da vil packstack bruke de samme passordene til de ulike komponentene og compute noden vil peke tilbake til controller noden slik at disse vil snakke sammen.

Mye av installasjon av compute noden er lik som forrige gang. Når alt i konfigurasjonsfilen er klart blir det kjørt på samme måte som tidligere med en liten endring. Istedenfor:

packstack --allinone

Blir det nå spesifisert en svarfil som brukes i installasjonen:

packstack --answer-file=$youranswerfile

Dag 4: Installasjon av OpenStack packstack

11. august var satt av til å installere OpenStack fra RDO. RDO er under utvikling av Red Hat og er en egen utgivelse av OpenStack laget spesifikt for å kjøre på RHEL, CentOSFedora og andre Red Hat baserte systemer.  For mer info om RDO vennligst se her.

Installasjon av RDO foregår ved hjelp av packstack. Packstack er et installasjonsverktøy som bruker Puppet moduler for å installere OpenStack på kompatible maskiner nevnt ovenfor. Har i denne posten valgt å ta med steg-for-steg installasjonen av RDO for å vise hvordan dette gjøres, se nedenfor for mer detaljer.

Vanligvis består OpenStack av tre hovedkomponenter; network, storage og compute, som hver kjører på sin egen maskin. Når man installerer packstack kan man velge at disse tre hovedkomponentene skal installeres på en og samme maskin. Dette kan være praktisk av flere grunner, i vårt tilfelle er det greit for å se hvordan det fungerer for testformål. Vi kan senere også velge å separere hovedkomponentene slik vi ønsker.

RDO installeres med 3 steg. Hentet fra http://openstack.redhat.com/Quickstart

Steg 1: Programvare repository:

Oppdater nåværende pakker på systemet:

sudo yum update -y

Sett opp RDO repositoriet:

sudo yum install -y http://rdo.fedorapeople.org/rdo-release.rpm

Steg 2: Installer packstack

sudo yum install -y openstack-packstack

Steg 3: Kjør packstack for å installere OpenStack

Packstack installerer automatisk OpenStack slik at man slipper å gjøre denne jobben manuelt. For å kjøre OpenStack på en enkelt node kan vi som tidligere nevnt kjøre denne kommandoen:

packstack --allinone

Etter installering vil packstack også generere en packstack-answer fil med passord og innstillinger som den bruker under installasjon. Denne kan så brukes om igjen til nye installasjoner eller til å lage nye noder med samme innstillinger. Om man installerer på andre maskiner vil man bli bedt om root passordet til maskinen før installasjonen starter.

Etter installasjon vil man kunne logge inn på panelet Horizon for å starte og administrere de instanser man måtte ønske. Mer om dette videre.

 

Dag 3: Videre feilsøking av OpenStack from scratch

8. august gikk mye av tiden til å feilsøke på hvorfor installasjonen fra gårsdagen ikke ville lage instanser.  OpenStack from scratch har en rekke tester en kan kjøre når installasjonen er ferdig. Testene ligger her: https://github.com/norcams/ofs/tree/master/tests

For eksempel vil import_image.sh importere et image som den virtuelle maskinen i instansen vil starte fra. Dette for å verifisere at glance image service fra OpenStack fungerer som det skal. I vårt tilfelle feilet 04-boot.sh som bruker komponenten nova til å starte den virtuelle maskinen. Det ble etterhvert mye lesing i nova loggene for å finne ut av feilen. Jeg hadde funnet frem til flere alternative løsninger fra nettet for å gjøre ting i en annen rekkefølge. Samt at jeg reinstallerte de tre  hovedkomponentene network storage og compute for å teste ut noen av løsningene. Dette ga ikke noen resultater.

Det har uansett vært interessant å ha installert dette fra bunnen av, selv om vi visste på forhånd at det ville være noen feil med installasjonen. Jeg har blitt fortrolig med flere av kommandoene på de verktøyene som er i bruk samtidig som jeg har fått et greit overblikk på hvordan komponentene fungerer sammen. I neste uke har vi tenkt å gå videre med en annen installasjon av OpenStack nemlig RDO.

 

 

 

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

Dag 1: Installasjon av arbeidsplass ved UIB

Fredag 4. august var første arbeidsdag på IT-avdelingen ved UIB. Jeg har tidligere jobbet her som lærling og ble godt tatt imot av både gamle og nye kolleger. Jeg skal jobbe med Iaas (Infrastructure as a service) og mine arbeidsoppgaver vil omfatte nettverk, lagring, compute og automasjon innenfor OpenStack rammeverket.

Som første dager flest gikk mesteparten av tiden til å installere arbeidsstasjonen samt å finne to skjermer som ville passe til.

2014-08-01 14.43.38

I mangel på kabinett ble arbeidsstasjonen min seende slik ut:

2014-08-18 14.09.08