Month: september 2014

Publisert

Dag 15 & 16: Testing og oppsett av Dell s4810 switcher og feilsøking av puppet moduler

Mandagen ble brukt til å konfigurere opp to nye Dell s4810 switcher som skal brukes til testformål i prosjektet. I motsetning til andre switcher som typisk kjører sitt eget operativsystem kjører disse switchene på Linux. Cumulus Linux er en variant av Debian og det er slike switcher som skal benyttes når den endelige skyplattformen installeres. Oppsettet vi laget og monterte i rack kan visualiseres på denne måten:

iaas ruting-redundans test - Network general-1

I tillegg har vi også jobbet videre med Foreman. Det er en del problemer som gjenstår før vi kan fullprovisjonere maskiner ved hjelp av puppet moduler. Etter at Foreman har provisjonert en maskin sliter vi med å få puppet modulene til å virke på maskinen. Fra tidligere fungerte modulene etter vi hadde oppdatert dem i forbindelse med «winch» prosjektet. Eneste endringen nå er at vi bruker Foreman. Videre feilsøking på mandag…

Publisert

Dag 14: Oppdatering av Foreman og installasjon av compute noder

Vi startet dagen med å feilsøke på hvorfor TFTP serveren til Foreman ikke ville fungere. Flere problemer oppstod med versjon 1.4.5 uten at vi fant noen gode forklaringer på hvorfor. Maskinen som Foreman er installert på kjører en DHCP server og en TFTP server. Disse tjenestene brukes når Foreman skal provisjonere opp maskiner. Da blir maskinene PXE bootet og den henter ned det aktuelle operativsystemet til maskinen og dette installeres automatisk.

Når en eldre pakke byr på problemer som ovenfor er løsningen som oftest å oppdatere til nyeste versjon. Alle installeringsscriptene til Foreman ble derfor modifisert slik at scriptet henter den nyeste programvaren fra repositoriet. Etter at Foreman hadde komt opp til versjon 1.6 fungerte TFTP serveren og det var nå mulig å provisjonere opp maskiner. Dette ble testet både på en fysisk maskin og på en virtuell maskin.

Når man skal provisjonere opp en maskin kan man velge fra en haug med templater på hva innstillinger man ønsker osv. Foreman tilbyr mye funskjonalitet og det er et stort verktøy å sette seg inn i. Heldigvis er dette noe vi skal holde på med en god stund fremover, og det alltid kjekt med bratte læringskurver.

Eksempelutdrag på et Foreman dashboard hentet fra google:

foreman

 

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