Noniin, vihdoinkin.. ihan ei kuukautta mennyt mutta tosi kauan kuitenkin.
Muutokset operaatiossa
BungeeCord ja spotti2 pyörivät nyt toistaiseksi ainakin hieman tehokkaammalla koneella. Jutut ja nimien käytöt on muutettu niin että jatkossa helpottuu se ettei kaikki palvelimet ole kumossa jos vastaavia syntyy vaan korjaus on nopeampaa (jos edes tarvitsee korjata).
spotti2 palvelimella pyörii nyt 1.14.4 versio minestä
spotti palvelimella mennään edelleen 1.13.2 versiolla (harkitaan sitten että koska tämä päivitetään ja onko se sitten 1.15 vai jotain muuta)
espotti.dy.fi:25577 on se minkä kautta kytkeydytään ja siihen voi ottaa yhteyttä kaikilla 1.13.2 -> 1.14.4 versioilla mutta päästäksesi spotti2 palvelimelle pitää olla käytössä 1.14.4 versio clientistä. Portaali toimii koneiden välillä (spawnin lähellä valkoinen) kuten myös /server spotti /server spotti2 komennot missä paikassa vain.
Selitteitä / kertausta
BungeeCord on portali palikka joka ottaa minecraft clientin kutsut vastaan. Käytännössä jokaisen pelaajan client juttelee BungeeCord ohjelman kanssa josta määritellään miten varsinaisille palvelimille kytkeydytään. Tämä mahdollistaa mm. portaalit palvelimien välille sekä eriversioiset palvelimet niin että mennään vain yhdellä clientillä (suurimman version mukaan). Tämän käytöstä on monta muutakin hyötyä ja mahdollistaa mm. helpomman laajentamisen jos käyttäjämäärä kasvaa.
ViaVersion palikkaa käytetään mahdollistamaan se että voidaan käyttää 1.14.4 clienttiä ja kytkeytyä sillä BungeeCord:iin jossa ViaVersion sitten tarvittaessa tekee conversion niin että BungeeCord ja pelaajan client voi kytkeytyä esim. 1.13.2 palvelimeen versiota vaihtamatta.
espotti.dy.fi portti 25577 BungeeCord palvelin jonka kautta kytkeydytään servereille
http://sp1.dy.fi:8123/ spotti (spotti1) palvelimen dynmap osoite
http://sp2.dy.fi:8123/ spotti2 palvelimen dynmap osoite
/server spotti komento jolla vaihdetaan palvelinta (tai /server spotti2)
Ongelman syy
Elikkäs joskus oli puhe että voisin päivittää amazon palvelinta nopeammaksi ja testattaisiin sitä joskus sitten viikonlopun ajan isommalla porukalla. No sitten kun aloin tuota päivitysoperaatiota tekemään palvelin ei enää toisen bootin jälkeen noussutkaan päälle tehokkaammalle palvelimelle.
Syitä oli monia. mm. Centos Linux updatet päivittivät kerneliä mutta jostain syystä dracut / grub2 ja initrd päivitykset eivät olleet tuolla kerralla toimineet oikein enkä ollut kiinnittänyt niihin aiemmin huomiota. Dracut oli uusi tuttavuus ja aiemmista grub jumpasta oli jo kulunut aikaa.
Amazon linux servereiden ongelmien debuggaus menee suurin piirtein seuraavasti:
a) boottaa palvelin ja kuvittele että se nousee
b) no sitten kun se ei nouse, niin n. 5min päästä näet check 1/2 ja kone ei päästä sisään
c) katso aws konsolista screenshot / logit ja ota ne vaikka copy pastella talteen
d) laita kone ajamaan alas (kestää n. 5min) Jos kyseessä spot instanssit tämä vielä vaikeutuu huomattavasti (ei kannata käyttää)
e) tutki logeja ja koita miettiä miten korjaisit
f) kun kone alhaalla detachaa levy ja odota etta detatched
g) liitä levy johonkin toiseen käynnissä olevaan koneeseen
h) kun levy liitetty aja tässä toisessa koneessa n. 10 komentoa että saat levyn toimimaan sopivalla tavalla
i) korjaa puoliksi sokkona toivoen että jutut auttaa (tää on itse se korjaus operaatio ja vain tämä nuo muut on vaan typerää overheadi)
j) irroita levy n. 10:llä komennolla tästä koneesta
k) detatchaa levy aws konsolissa ja odota n. 1min
l) attachaa levy siihen alkuperäiseen koneeseen (muista että se pitää olla /dev/sda1)
m) boottaa kone ja toivo että se ei taas pysähdy 1/2check eikä pästä sisään
No kun tuohon ylläolevaan sitten lisätään vielä että testimielessä olin sp2 koneelle ottanut erilaisia levyjärjestelmiä käyttöön ja yhdistetään vielä niihin jossakin vikatilanteessa tapahtunut levyjärjestelmän vaurio joka esti levyn mounttaamisen minkä virheilmoitukset olivat melko huonot oli korjaus erittäin paljon aikaa vievä.
