Dit is een beetje een geval van "ik wil er wel over bloggen, maar eigenlijk moet ik dan zoveel achtergrondinformatie meegeven, dat het geen blogje meer is". Ik ga het toch een beetje proberen, en dan neem ik maar voor lief dat het een technisch en voor de meeste mensen niet helemaal te volgen verhaal is.
Misschien vul ik later eens een pagina met wat algemene achtergrond, dan kan ik daarnaar verwijzen, of zo. Of lezers gebruiken het onvolprezen reactiegebeuren om om opheldering te vragen.
Ik ben bezig geweest met een ticket, en ik heb er zelf weer het nodig van geleerd over onze platformen en hoe die in elkaar steken; voor het oplossen was ik dan ook afhankelijk van (en dankbaar voor) de hulp van collega's en onze hulplijn.
Help, ik kan niet inloggen
Dat was de strekking van het support-ticket dat ik oppakte. Een gebruiker kon niet meer inloggen op hun "server" op ons Merlin-cluster. Prima, kan allerlei redenen hebben, de eerste check is dan: draait dat ding überhaupt.
Eh, nee, die draait niet, al sinds november niet meer.
Er is in die periode wat werk verricht met versies en zo, en er moesten dus wat VMs heen en weer geschoven worden, en daarbij is deze niet meer opgekomen.
OK, kan gebeuren, ik start het ding weer en een tevreden klant... hee, hij verdomt het om op te starten.
Op meerdere manieren de VM starten of herstarten, of uiteindelijk zelfs de hele hypervisor waar-ie op draait (op dat moment als enige, vandaar dat dat een optie was) maakte niks uit: het ding was stuk en in error en u zoekt het maar uit.
Help, mijn opslag is weg
Met wat graafwerk in de logs kwam ik er wel op uit dat er wat gedoe was met het verbinden met Ceph, de opslaglaag van het cluster waar de volumes van alle VMs op zijn opgeslagen (die staan dus niet op de hypervisor zelf, maar worden over het netwerk heen benaderd). Connection timeout, want er wordt geprobeerd te verbinden met een verkeerd (verouderd) IP-adres, en nou ja, geen volume is natuurlijk wat lastig opstarten.
De hulplijn neemt een kijkje in de database die het cluster bijhoudt met informatie, en ja, daar blijkt inderdaad dat daar de verkeerde IP-adressen staan. Ze lossen dat voor dit geval op door de database wijs te maken dat de betreffende server actief is, de volumes één voor één te ontkoppelen en daarna weer aan te koppelen (waarbij de nieuwe verbindingsinformatie wordt gebruikt), maar dat is natuurlijk wat hacky. In dit geval wel handig, want het is een beetje een aparte instance: er hangt — soort van op afstand — een GPU in.
Help, er zijn er nog meer
De hulplijn kijkt ook nog even in de database of er meer van die gevallen zijn met verkeerde IP-adressen, en jawel, 25 stuks met hetzelfde euvel. Een redelijk deel daarvan is niet actief (en kan mogelijk zelfs opgeruimd worden, dus dat is een item voor het backlog), en een deel draait op dit moment (maar zou dus op den duur hetzelfde probleem kunnen vertonen en niet meer willen starten).
Er is ook nog de suggestie dat het live migreren van een instance ook het probleem zou kunnen oplossen, zodat-ie dus niet afgesloten hoeft te worden. De VM wordt dan, al draaiende, van de ene hypervisor naar de andere verplaatst.
Ik zoek een machine waarvan het geen supergroot drama is als die even zou omvallen, en ga aan de slag.
Althans, ik probeer dat; ik klop braaf de juiste OpenStack-commando's in, maar vervolgens gebeurt er niets en van de logs wordt ik ook niet veel wijzer. Gelukkig wijst een collega me erop, dat ik probeer een VM van een hypervisor op een Intel-machine naar een hypervisor op een AMD-machine te schuiven, en dat kan niet, althans, niet live.
Geholpen
Ik snor een Intel-machine op en probeer het nog en keertje, en waarempel, een paar minuten later draait de betreffende VM op zijn nieuwe stek. Niet alleen dat, maar als ik in de database kijk, kloppen nu de IP-adressen van de Ceph-verbindingen ook. Probleem opgelost, dus.
Wat nou de precieze oorzaak is geweest, is nog wat onduidelijk, maar we neigen naar "de verandering heeft plaatsgevonden toen de getroffen VMs niet draaiden, en dus niet de nieuwe configuratie mee hebben gekregen".
Nu nog even dat langere lijstje doorspitten en splitsen in "opruimen" en "fixen", maar dat komt later.