Tag: feilsøking

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 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 3: Videre feilsøking av OpenStack from scratch

8. august gikk mye av tiden til å feilsøke på hvorfor installasjonen fra gårsdagen ikke ville lage instanser.  OpenStack from scratch har en rekke tester en kan kjøre når installasjonen er ferdig. Testene ligger her: https://github.com/norcams/ofs/tree/master/tests

For eksempel vil import_image.sh importere et image som den virtuelle maskinen i instansen vil starte fra. Dette for å verifisere at glance image service fra OpenStack fungerer som det skal. I vårt tilfelle feilet 04-boot.sh som bruker komponenten nova til å starte den virtuelle maskinen. Det ble etterhvert mye lesing i nova loggene for å finne ut av feilen. Jeg hadde funnet frem til flere alternative løsninger fra nettet for å gjøre ting i en annen rekkefølge. Samt at jeg reinstallerte de tre  hovedkomponentene network storage og compute for å teste ut noen av løsningene. Dette ga ikke noen resultater.

Det har uansett vært interessant å ha installert dette fra bunnen av, selv om vi visste på forhånd at det ville være noen feil med installasjonen. Jeg har blitt fortrolig med flere av kommandoene på de verktøyene som er i bruk samtidig som jeg har fått et greit overblikk på hvordan komponentene fungerer sammen. I neste uke har vi tenkt å gå videre med en annen installasjon av OpenStack nemlig RDO.