Kuva: ”tarazan” CC BY-NC-SA.
Valitettavasti kaikille yhdistyksen palvelimilta irkkaaville jäsenille on tullut varmasti selväksi, että Kapsin palvelinten Linux-ydinten kanssa on vakavia ongelmia. Avaan tässä hieman tiedotteita yksityiskohtaisemmin mitä ongelmat koskevat, mitä asialle on tehty ja tullaan tekemään.
Verkkokortit
Ilmeisesti lähinnä kuormituksen kasvettua Lakka-palvelimella Siilo-levytilan käyttöönoton jälkeen verkkokortit alkoivat oireilla. Käytännössä palvelimen kahdesta verkkokortista toinen (eth0 tai eth1) meni sellaiseen tilaan että liikennettä ei enää kulkenut. Käytännössä kun sisäverkon kortti tipahti, yhteys NFS-verkkolevypalvelimeen meni poikki ja kaikki verkkolevyä käyttävät ohjelmat (kaikki käyttäjien ohjelmat) menivät jumiin. Jumitus jouduttiin purkamaan uudelleenkäynnistyksellä. Vastaava ongelma on ilmennyt aiemminkin lakalla ja xobilla pidemmän aikaa sitten, mutta ei aiemmin ole toistunut. Oletettavasti uudentyyppinen liikenne sattui olemaan sellaista, joka saa vian esiintymään useammin.
Ongelma liittyi Broadcomin verkkokortteihin tietyllä firmware/ajuriversiolla. Valitettavasti uudempaa ajuria ei saatu käytössä olevan Linux-ytimen 2.6.32.y-sarjan versioon. Ongelma ratkaistiin vaihtamalla tärkeimmille koneille verkkokortit Intelin valmistamiin kortteihin.
NFS ja lukkiutumiset
Aluksi osa jumituksista ja kaatumisista kategorisoitiin Linuxin NFS-toteutuksen huonoudeksi. Todellisen vian selvittäminen on hankalaa ja vaikka osa virheistä onkin antanut ymmärtää, että NFS voisi olla syyllinen, vika on voinut olla osassa tapauksista myös verkkokortin ajurissa.
Nyt ongelmana Lakalla on ollut jumittumisia, joissa kaikki prosessoriytimet ovat odottamassa lukon vapautumista eikä niistä yksikään tee mitään hyödyllistä. Tällainen tilanne johtuu ohjelmointivirheestä ytimessä ja siitä toipumiseksi kone on käynnistettävä uudelleen. Tuotantokoneella viasta ei olla onnistuttu kaivamaan riittävän paljon tietoja, jotta vian aiheuttaja saataisiin jäljitettyä. Vastaavaa ongelmaa ei kovasta yrityksestä huolimatta ole saatu toistettua testaukseen tarkoitetulla Paskanmarja-palvelimella. Ilmeisesti vian toistamiseen tarvittavaa tavallista käyttöä matkivaa testikuormaa ei ole onnistuttu toistamaan riittävän hyvin testiympäristössä. Koska vikaa ei saada toistettua hallitusti, sen löytäminen on äärimmäisen vaikeaa ja korjaaminen mahdotonta. Tietysti on mahdollista, että joku Linux-kehittäjistä törmää samaan ongelmaan ja korjaa sen tai kirjoittaa vian aiheuttavan osan koodia uudestaan muun kehityksen yhteydessä.
Hilla on kaatunut nyt useita kertoja niin, että kaatumisesta ei ole jäänyt mitään jälkiä. Vian etsiminen ilman mitään tietoja kaatumisesta on vielä edellistäkin vikatyyppiä vaikeampaa. Koska kaatumisia on tapahtunut usein, otettiin käyttöön Linux 2.6.38-sarjan ydin, jossa ainakin osa Lakalla saaduissa virheilmoituksissa esiintyneistä osista on kirjoitettu uudelleen. Ydintä ei ole ehditty vielä kovin kattavasti testata (joskin yksi vakava bugi siitä jo testauksessa 12 tunnin rasituksen jälkeen löydettiin ja korjattiin). Se otettiin silti käyttöön ajatuksella “eihän se ainakaan huonompi voi olla kuin edellinen”. Aiempi ydin kun ei tunnu pysyvän enää vuorokautta pidempään kunnossa. Ainut järkevä arvaus tuntuu olevan että jokin käyttäjien aiheuttamassa kuormassa on muuttunut, mikä on johtanut vian toistumiseen. Tai tietysti voi olla että vika tulee muuten vain esiin helpommin Debian Squeezen uudemmilla ohjelmilla.
Yksittäiset ongelmat
Vaikeasti toistettavien vikojen toistamisessa ja paikantamisessa yksi huomattava lisäongelma on, että yhdistyksen ytimet eivät ole ns. vanilla-ytimiä eli suoraan kernel.orgin puusta. Yhdistys käyttää esimerkiksi grsecurity-patchiä, joka mm. sisältää suojakeinoja erilaisia hyökkäyksiä vastaan. Toinen käytössä oleva isompi muutos on BFS-skeduleri. Ennen BFS:n käyttöönottoa paljon CPU-aikaa vievät prosessit haittasivat muun järjestelmän vastenopeutta (interaktiivisuutta). BFS:llä CPU-käyttö ei ole enää ollut ongelma.
Ongelma on, että jos törmäämme johonkin epämääräiseen ongelmaan ja epäilemme että se voisi olla jossain kolmessa mainitusta komponentissa (kernel.org Linux, grsecurity, BFS), niin siitä raporttia lähettäessä ensimmäisenä ehdotetaan kokeilemaan toistuuko puhtaalla kernel.org-ytimellä. Jos ongelma on alunperinkin sellainen ettei sitä saada testiympäristössä toistettua, päädytään melko toivottomaan tilanteeseen. Tuotantoympäristössä ei voi hirveästi myöskään kokeilla kovin suuria muutoksia, varsinkaan jos niiden toimivuudesta ei ole mitään takeita.
Yhteenveto
Yhteenvetona ongelman vakavuus siis on todellakin niin yhdistyksen ylläpidon kuin hallituksen tiedossa ja tilanteen ratkaisu on ensiarvoisen tärkeää ja sen eteen tehdään kovasti töitä. Ylläpitäjät ovat käyttäneet useiden työpäivien verran omaa aikaansa uuden Linux-ytimen testaamiseen, ongelmien selvittämiseen ja korjaamiseen. Siis vapaaehtoistyötä. Jäseniltä tulevat kyselyt ”milloin ongelma korjataan” ovat siis sinänsä oikeutettuja, mutta kun tilanne tuntuu toivottomalta, kysymykset tuntuvat ikävältä. Kysymysten tai jopa haukkujen toistaminen ei ole kehittävää vaan on pois siltä työpanokselta, jonka vapaaehtoiset (ja pätevät) ylläpitäjämme jaksavat käyttää oikeiden ongelmien ratkomiseen.
Me ylläpidossa ja hallinnossa olevat olemme myös käyttäjiä ja muiden käyttäjien tavoin haluamme erittäin paljon, että kaikki palvelut toimisivat vakaasti ja ongelmitta. Ylläpitäjien parhaasta ja oikeasti kovasta yrityksestä huolimatta ongelmilta ei ole nyt vältytty. Toivotaan, että tehdyistä korjauksista olisi nyt apua Hillalla tai ainakin ‘lopullinen’ ratkaisu ydinongelmiin löydettäisiin pian.
Epäilemättä kovin turhauttavaa. Eiköhän selkeästi suurin osa ymmärrä tilanteen monimutkaisuuden ja hyväksy tilanteen sen kummemmin syyttämättä. Eihän Kapsi idealtaan ole muutenkaanmikään puoli-ilmainen hosting-palvelu 🙂
Suuri kiitos ylläpidolle, ja toivottavasti vaikeaan tilanteeseen löytyy järkevä ratkaisu ilman hirveää kikkailua 🙂
Jes. Toivottavasti vika löytyy ja tsemppiä ylläpidolle! 😀
”[Hillan] aiempi ydin kun ei tunnu pysyvän enää vuorokautta pidempään kunnossa. Ainut järkevä arvaus tuntuu olevan että jokin käyttäjien aiheuttamassa kuormassa on muuttunut, mikä on johtanut vian toistumiseen.”
Voihan tietysti myös uudessa raudassa olla jotain vikaa, Hillahan otettiin käyttöön hyvin hiljattain. Tämä korreloisi myös virheilmoituksettoman kaatumisen kanssa, mutta on tietysti yhtä vaikea todentaa.
Kiitokset esimerkillisestä tiedottamisesta ja ongelmankuvauksesta. Tsemppiä matkaan!
mukava lukea tällaista tiedotusta. Tietää miten paljon kapsiin panostetaan!
Suurkiitokset ylläpidolle onglmien korjaamiseen käytetystä vaivasta ja ajasta!
Tsemppiä ja jaksamista teille!
Broadcomin kanssa ollut muillakin ongelma, myös Windowsin kanssa:
http://blog.serverfault.com/post/broadcom-die-mutha/
Palvelimessa on siis Debian Squeeze, mutta itse patchattu ja käännetty kerneli? Onko aivan varma, että ylläpitäjien asiantuntemus riittää tällaiseen? grsecurity varsinkin on suuri ja invasiivinen patchi. Vastaako sen käyttö johonkin todelliseen tarpeeseen?
Voisin valottaa tässä lyhyesti Kapsin kernelihistoriaa. Tai ainakin sitä osaa siitä, mikä itse olen päässyt seuraamaan.
Custom-kerneleiden käyttö kapsilla alkoi oman tietoni mukaan jo hyvin varhaisessa vaiheessa yhdistyksen historiaa. Tuolloin käytössä oli 2.4-sarjan kerneli, johon oli lisätty niinsanottu ha-patch. Kyseisen pätsin idea on eriyttää käyttäjät toistensa tiedostoista kernelitasolla, joten väärät chmodit eivät paljasta käyttäjien tiedostoja toisille käyttäjille.
2.6 kerneliversioon siirtymisen jälkeen jossain vaiheessa on otettu käyttöön grsec ja sitä on käytetty siitä eteenpäin aina nykypäivään asti. Käytännössä kernelin major versioissa seurataan melko tarkasti grsecin stable releaseja.
grsecin tarkoitus on antaa mahdollista lisäaikaa tutkia ja päivittää kernelin haavoittuvuudet ilman, että koneita on välttämätöntä sammuttaa välittömästi kernelihaavoittuvuuden löydyttyä. Näin monen käyttäjän koneella kyse on yleensä vain minuutista, kun jotain vääriin käsiin päätynyttä tunnusta käytetään exploitin yritykseen.
grsecin lisäksi reilu vuosi sitten otettiin Kapsin kerneleissä käyttöön BFS-patch. Tuolloin lakalla oli pahoja ongelmia selvitä silloisesta, yli 1000 käyttäjää pienemmästä kuormasta vaikka CPU:ta oli sinänsä paljon vapaana. Tutkimme tilannetta ja totesimme linuxin CFS-schedulerin selviytyvän verrattoman huonosti shellikoneen kaltaisesta kuormasta. BFS:n myötä tilanne muuttui erittäin radikaalisti. Loadit tippuivat ruuha-aikoinakin entisestä 10 – 20 tasosta alle yhteen ja SSH lakkasi lagaamasta havaittavasti. Nyt vuoden ja lähes 1500 käyttäjän lisäyksen jälkeen voin hyvillä mielin todeta ratkaisun olleen erittäin hyvä.
Vuodentakainen skaalautuvuusongelma johtui siis selkeästi prosessi-schedulerista. Tämän hetken ongelmat liittyivät ilmeisesti kernelin VFS implementaatioon, joka on kirjoitettu uusiksi Linuxin 2.6.38 -versioon, joka on nyt käytössä Hillalla. Nähtäväksi jää mikä on seuraava pullonkaula, joka Kapsilla tulee vastaan Linux-kernelin kanssa.
Kiinnostuneet voivat vilkaista CFS -> BFS muutosta talteen nappaamistani munin-kuvaajista: http://warod.kapsi.fi/b/bfs/
Huomioimisen arvoista on erityisesti Interrupts ja sshd -käppyrät, jotka näyttävät koneen käytön reaalisen kasvun. Tämän jälkeen on hyvä sitten katsastaa ainakin CPU ja VMstat -käppyrät, jotka puolestaan puhuu karua kieltä CFS schedulerin sopimattomuudesta Lakan kaltaiseen työkuormaan.
Pingulla on sydän väärässä kohdassa. 🙁
Kannattaa kokeilla ottaa HP:n palvelimien biosista C-statet pois päältä. Tuo ainakin yleensä korjaa broadcom verkkokorttien ongelmat ja mahdollisesti voi korjata nykyiset verkko-ongelmat myös Intelin korttien kanssa.
Eikös jo kohta kannattaisi vaihtaa se linux pois ja laittaa tilalle parempaa kuten Solaris.
Valtteri, C-statet poistettiin taannoin eikä se korjannut broadcomin ongelmia. Ongelmat ovat voineet sen jälkeen poistua kernelipäivitysten myötä. Intel-vaihdoksen jälkeen ei ole verkon kanssa ongelmia esiintynyt meidän puolella.
Sami, Ajatuksella on toki leikitelty ja onhan meillä siika, joka toimii OpenIndianalla. Solarispuolella ongelma on se, että tuettu Solaris maksaa ihan hervottomia rautoineen ja avoimen lähdekoodin ilmaiset jakelut ovat vielä murrosvaiheessa Oraclesta irtautuessaan. Toistaiskesi ajetaan siis vain tiedosto backendinä ’solkkua’. Katsotaan mitä tulevaisuus tuo tullessaan.
Täytyy vielä sen verran sanoa, että Ilkka on tehnyt kernelin kanssa mahtavaa työtä ja nykyisellään ollaan saatu havaittavasti toimivampi kerneli alle. Sinänsä jännä, että osa bugeista on olleet luonteeltaan sellaisia, että ne tulevat väistämättä vastaan, kun linux-järjestelmän käyttöä skaalaa ylöspäin. Hyvin jännittävä piirre, että ne huomattiin vasta Kapsin käytössä.
Kyllä varmaan valtaosa palveluista kannattaa säilyttää Linux:in päällä ellei sitten kaikkikin. Johonkin erityistarkoitukseen Solaris voi olla hyvä, mutta se kuitenkin karsii helposti osaajien määrää paljon pienemmäksi ja sielläkin erinäisiä ongelmia löytyy.
Tuo Broadcom ongelma on ollut laaja ja varmasti niiden vaihto on ollut hyvä asia. Hyvä kun on töitä jaksettu asian eteen tehdä, eikös tuo nyt jo näytä paljon paremmalta.