Category: packstack

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