FinWX:n keskitetyn levyjärjestelmän huoltotyö ohi

[J.Jäntti]

FinWX:n keskitetyn levyjärjestelmän huoltotyö on saatu onnellisesti (noin suunnilleen ainakin) päätökseen.
Työ aloitettiin perjantai/lauantai-vuorokaudenvaihteessa ensin siirtämällä foorumi huoltotilaan, jonka jälkeen kaikki virtuaalikoneet ajettiin hallitusti alas ja ESXi Server asetettiin huoltotilaan.

Levypakka ajettiin alas ja otettiin huoltopöydälle asennustöitä varten. Itse levyn asennusoperaatio vei vain pienen hetken, jonka jälkeen levyjärjestelmä asennettiin takaisin paikalleen ja uuden levyn esittäminen levyjärjestelmälle oli edessä. BIOS ja Intelin RAID-ohjain näkivät levyt ja hetken kuluttua käyttöjärjestelmä latautui.

Asiat eivät olleet levyn loogisen esittämisen puitteissa niin yksinkertaisia kuin olisi toivonut. Web-käyttöliittymässä levy löytyi, se oli formatoimaton ja käytännössä valmiina käyttöön, mutta tästä huolimatta levyä ei näkynyt formatointivalikossa lainkaan vaihtoehtona. Netin syövereistä löysin NAS4Free:n keskustelupalstan ketjun, jossa juuri tätä samaista ongelmaa käsiteltiin. Useammilla oli ollut sama murhe. Osa oli saanut levyn formatoiduksi formatoimalla se jollain tunnetulla tiedostojärjestelmällä toisessa koneessa ja lisäämällä se sitten takaisin järjestelmään. Osa taas sanoi että levyn paikan vaihtaminen SATA-väylässä korjasi tilanteen ja osalla vika oli lopulta itse raudassa. Lopulta ratkaisu löytyi mutta se oli jotain ihan muuta kuin looginen ja sai sydämen naputtamaan huolestuneesti: Piti mennä ZFS-järjestelmään pakkosynkronoimaan koko levypakan konfiguraatio uudelleen, pakkoylikirjoittamalla jo olemassa olevien levyjen data (joka ei muuta todellisuudessa muuta, kuin tiedostojärjestelmän arvoa toiseksi. Järjestelmä varoitti useaan otteeseen ettei tämä olisi hyvä idea, koska pakka oli rikki mutta jälleen kerran FinWX ja kaikki sen palvelut joutuivat hiuskarvan varaan, kun levy piti saada näkyville. Pakkosykronointi onnistui ja vaikka ulkonäollisesti mitään ei näyttänyt tapahtuvan, yhtäkkiä uusi levy olikin formatoitavissa. Käyttäjät epäilivät kyseessä olevan bugi.

Levy saatiin ZFS:n näkyville, mutta sitten juostiinkin potkaisemaan seuraavaa kynnystä niin että varpaat rutisivat: Levyä ei saatu web-käyttöliittymän "Replace"-toiminnon kautta linjoille lainkaan, koska levy ei näkynyt listoilla lainkaan. Vanha levy oli jo offline-tilassa, ja Online-tilaa varten tarjottiin jostain täysin käsittämättömästä syystä levyjä jotka olivat jo Online-tilassa. "Detach"-toiminto ei näyttänyt mitään levyjä ja vastavuoroisesti "Attach"-toiminto tarjosi molempia Online-tilassa olevaa levyä, muttei tätä uutta. Jälleen kerran netin syövereistä löytyi samainen keskustelupalsta ja siellä, jälleen kerran epäiltiin bugia ja ehdotettiin suoraan että järjestelmälle annetaan replace-komento sen omassa komentokehotteessa. Yllättäen, jälleen, järjestelmä huuteli, ettei kehotteen käyttö ole suositeltavaa eikä ole tuettu, mutta koska levyä ei normaalikeinoin saatu linjoille, se piti komentaa manuaalisesti esille. Komento onnistui, levy liittyi osaksi ZFS-levyjärjestelmää ja palautusprosessi (Resilver) alkoi kello 00:54.

Ajattelin tässä kohtaa nostavani ESXi:n pois huoltotilasta, mutta tulin toisiin aatoksiin nopeasti, kun ESXi:n lokeihin tuli tasan kymmenen minuutin välein tuttu ilmoitus:
Warning:
Frequent PowerOn Reset Unit Attentions are occurring on path vmhba37:C0:T0:L0. This might indicate a storage problem.
Affected device: t10.FreeBSD_iSCSI_DISK______NFSN00AZWRF80H__________________.
Affected datastores: datastore-nas-raidz1

Päätin että on parempi antaa järjestelmän palautua ensin ennen kuin sille aletaan ajamaan kuormaa. Näin myös teinkin ja kello 03:59 palautus oli suoritettu. Oli aika ottaa ESXi huoltotilasta ja käynnistää virtuaalikoneet.
Kaikki meni niin pitkään hyvin kunnes käynnistin pelikäytössä olevan dedicated serverin. Kun sen aiheuttama tietoliikennekuorma nousi yli iSCSI-väylässä yli 150Mbit/s, koko levyjärjestelmä vetäisi Kernel Panicin ja käynnisti itsensä uudelleen. ESXi jäi limboon ihmettelemään kun levyjärjestelmä ykskaks lakkasi vastaamasta. Kun järjestelmä sai itsensä ylös, jatkettiin siitä mihin jäätiin ja kun kerran jäätiin Kernel Panic:n aiheuttamaan tilanteeseen, siihen mentiin uudelleen. Levyjärjestelmä pomppi kolme kertaa suoraan ylös-alas ennen kuin sain pakolla virtuaalikoneen sammuksiin. Tämän jälkeen järjestelmä rauhoittui. Käynnistin virtuaalikoneen uudelleen testin nimissä ja jälleen kerran kun 150Mbit/s ylittyi, hakkasi järjestelmä lähes 60 SCSI-väylän TASK ABORT-komentoja parissa sekunnissa, heitti Kernel Panicin ja kaatui taas. Nyt olin varma että kyse oli juuri tuosta virtuaaliserveristä, joten pakotin sen alas, eristin sen ulkomaailmalta, siirsin USB-tikulle kaikki tarpeelliset datat sieltä ja sitten pistin virtuaalikoneen tuhannen päreiksi. Kun kone lähti levyltä, jotain outoa tapahtui: ESXi lakkasi huutelemasta latenssivaroituksia ja mitään muitakaan herjoja ei enää tullut. Kone myös kesti kaikki, jopa yli 600Mbit/s tapahtuneet tiedonsiirrot nikottelematta. En pysty edelleenkään päättelemään mitä vikaa juuri tuossa virtuaalikoneessa oli, mutta jollain tavalla se oli niin rikki, ettei ESXi sitä nähnyt enkä siten minä sille mitään pystynyt tekemään. Levyjärjestelmän käyttöliittymä- ja logiikkaongelmien, sekä virtuaalikoneen aiheuttaman Kernel Panic-murheiden vuoksi katsoin parhaaksi pysyttäytyä toistaiseksi edelleen 9.3-versiossa levyjärjestelmän osalta, enkä sitä näin ollen päivittänyt, vaikka se tehtävälistalla olikin.

Totesin järjestelmän vakaaksi ja otin foorumin pois huoltotilasta kello 05:10 ja huoltotyö päättyi kello 05:15.
Takarajaksi oli asetettu kello 04:00 ja huoltotyö venyi tunnin ja vartin sen yli.

FinWX:n ylläpito pahoittelee katkoksesta ja sen venymisestä aiheutunutta haittaa.