Innlegg

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.

Publisert

Dag 11: Videre oppdatering av «winch» repository

Siden «winch» ble laget for å støtte en eldre versjon av OpenStack ble det nødvendig å oppdatere flere av puppet modulene til å nyeste versjon. Uten dette feilet installasjonen momentant og det var ikke mulig å provisjonere opp maskiner med puppet når modulene var utdaterte. Etter at disse ble oppdatert gikk installasjonen overraskende nok gjennom. Vi klarte å sette opp en controller node og en compute node.

Vi har tidligere holdt på med packstack som kjører alle OpenStack komponentene på en og samme node. I et produksjonsmiljø vil vi heller separere de ulike komponentene. Dette er av flere grunner; hver maskin skal bare kunne gjøre det de er satt til, det vil lette trykket i forhold til bare en og samme node, og det er mer oversiktlig og skalerbart. Alle de forskjellige komponentene ligger under sine respektive nett, her er en oversikt over hvordan det ser ut:

RolesProfiles

Etter at controller og compute noden kom opp kjørte vi de forskjellige testene som fulgte med winch. Disse testene verifiserer funksjonalitet og setter samtidig opp nettverk, rutere, og instanser.  Nå har vi en kjørende instans og selve oppsettet ser ut til å fungere greit. Opplever nå at instansen ikke kan nås fra controller noden, så dette er noe vi må feilsøke videre på mandag.

Publisert

Dag 10: Feilsøking av instansnettverk & installasjon av «winch»

Første del av dagen ble brukt til videre feilsøking av hvorfor instansene våre ikke kunne snakke ut mot verden. Dette ble løst med å spesifisere hvilket interface vi skulle kjøre maskering ifra. Iptables regelen fra OpenStack networking in too much detail ble modifisert til å se slik ut:

iptables -t nat -I POSTROUTING 1 -s 172.24.4.224/28 -o eth0 -j MASQUERADE

Etter en iptables reload kunne instansene våre snakke ut mot verden. Innenfor sine begrensede parametere kunne vi nå si at vi hadde en fullverdig OpenStack installasjon.

Resten av dagen ble benyttet til å se på «winch» prosjektet fra GitHub. Dette er et prosjekt på lik linje med OpenStack fra scratch. Formålet med winch er å lære oss å deployere OpenStack ved hjelp av puppet moduler og The Forman. Kort forklart er Forman en effektiv måte å installere all infrastruktur til OpenStack installasjonen, eksempelvis compute, storage og network. Foreman gir mye spennende funksjonalitet, så anbefaler videre lesning i linken over. Når «winch» ble laget var OpenStack kommet til havana versjonen. I disse dager bruker vi icehouse, som er samme versjon som ble installert ved hjelp av packstack. For å kunne jobbe videre med «winch» er vi først nødt til å oppdatere denne til å støtte icehouse. Dette vil være klart til neste gang.

 

Publisert

Dag 9:Tilbake til packstack –allinone og installasjon av fysisk controller

Etter at minnetildelingen hadde blitt økt flere ganger på vår virtuelle controller node bestemte vi oss for å installere denne på en fysisk maskin. I tillegg hadde vi også hatt problemer med neutron-server, så i denne omgang gikk vi tilbake på å kjøre packstack –allinone. Dette ville forhåpentligvis gjøre slik at vi unngikk flere problemer, hvertfall nå som vi er i en testfase.

Vi installerte på samme måte som tidligere. Fra før av har man en helt ny installasjon av CentOS, og dermed følger man de tre stegene som jeg har skrevet om tidligere her. Noen av de tingene vi har slitt med fungerte med en gang. Både neutron-server og det å lage instanser fungerte uten problemer.

Det som gjenstår nå er å kunne få instansene til å snakke med verden på utsiden. Dette gjør vi ved å utføre noen av de siste stegene i OpenStack network in to much detail. Det blir satt en offentlig IP adresse til OpenStack på br-ex interfacet. Samtidig som vi legger til brannmurregler slik at trafikk på innsiden av skyen blir maskert og videresendt gjennom noden og videre ut på  nettet. Vi fikk litt problemer etter at reglene var lagt inn i brannmuren. Instansene klarer ikke å pinge ut i verden. Det eneste instansen klarer å pinge er controller noden og vice versa.

Neutron_architecture

 

Publisert

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.

 

 

Publisert

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.

Publisert

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!

 

Publisert

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
Publisert

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, CentOS, Fedora 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.