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

 

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.

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!