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

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!