Järjestelmän laatu mitataan poikkeustilanteissa

Normaalin vikaraportin sijasta ajattelin kirjoittaa tapahtuneesta vikatilanteesta blogitekstin. Vikaraportti vastaa tyypillisesti kysymyksiin: ”1. Mitä tapahtui?” ja ”2. Miten varmistetaan, että tämä ei tapahdu enää ikinä uudelleen?”

Blogitekstissä voin käsitellä sen, mitä tekniikan puolelta tilanteen ”ollessa päällä” oikeasti koettiin.

Käytännössä noihin kysymyksiin voi vastata bisnesvastaukset (jotka löytynevätkin vikatiedotteesta):

  1. Levyjärjestelmässä tapahtui poikkeuksellinen häiriötilanne normaalin ylläpitotoimen yhteydessä
  2. Opimme tapahtuneesta ja olemme tarkempia tulevaisuudessa, lisäksi osaamme tunnistaa nyt tapahtuneen ilmiön oireet nopeasti

Kysymyksiin voi myös antaa teknisen henkilön suorat vastaukset:

  1. Vikatilanne, joka näkyi klusteroidun järjestelmän eri jäsenille eri tavoilla aiheutti kaskadivirheen useiden varotoimintojen aktivoituessa ristiin ja automaattiset korjaavat toimet aiheuttivat pahemman ongelman, jonka korjaaminen vaati ihmisen väliintuloa ja huolellisia tarkistuksia.
  2. Tilanne tuskin toistuu, vaikka yritettäisiin toisintaa myöhemmin. Harvinainen ongelma ja asioiden yhteensattuma. Harvinaisia ongelmia tapahtuu silloin tällöin. Tapahtumistaajuus on luokkaa yhden kerran useiden vuosien jaksolla. Vähän sama kuin koettaisi ennustaa historiatilastoista seuraavaa tulivuorenpurkausta. Tiedossa on, että joskus jotain todennäköisesti tapahtuu tilastojen valossa, mutta et voi tietää koska.

Toisaalta tämä kasvatti vikatilanteessa tehtävien ”perustarkastusten” listaa taas muutamalla.

Kaikki tekniikan parissa tietävät, että yllättäviä vikoja ilmenee, eikä niitä kaikkia voi estää kokonaan.

Ongelmien seurauksia voidaan kuitenkin kontrolloida. Ymmärrän että asiakasnäkökulmasta kaikki katkokset ja häiriötilanteet ovat kestosta riippumatta yleensä kestämättömiä. Kuitenkin on vielä yksi asia, joka on vielä kestämättömämpää: datan menettäminen tai datan eheyden menettäminen.

Datan menettäminen viittaa suoraan tiedon häviämiseen. Eheyden menettäminen taas viittaa siihen, että ei ole varmuutta siitä, onko järjestelmään tallennettu data ehjää vai onko data mahdollisesti rikkoutunut kelvottomaksi, vaikka näennäisesti kaikki on ok. Tällainen vika havaitaan vasta, kun dataa yritetään lukea järjestelmästä. Eheyden menettäminen on erityisen ongelmallista, koska se saatetaan havaita vasta pitkän ajan kuluttua.

Käytännössä nyt tapahtunut ongelmatilanne vahvisti omaa näkemystäni siitä, että meillä Vaultstack-alustalla käytetty avoimen lähdekoodin Ceph-tallennusjärjestelmä on ehdottomasti paras ratkaisu, kun halutaan varmistua siitä, että yllättävässäkin tilanteessa data on tallessa ja se on eheää.


Näistä esisanoista voimme siirtyä varsinaiseen tapahtumaketjuun tekniikan silmin havainnoituna. Täten tekstin sisältöä ei ole tarkoitettu pikatiivistelmästä kiinnostuneille.

Varoituksen sana myös mahdollisesti samassa tilanteessa apua etsivälle: kyseessä ei ole vaihe vaiheelta etenevä tekninen ohje. Mukana ovat vain olennaisimmat ja mielenkiintoisimmat työvaiheet sekä toimenpiteet. Jos et ole varma siitä mitä teet, jätä tekemättä ja kysy apua. Kaupalliset tuotteet ja niiden tukipalvelut ovat olemassa hyvästä syystä. Cephin tapauksessa saat virallista tukea esimerkiksi Canonicalilta [Ubuntu] ja RedHatilta.

Kehittäjiltä voi saada myös tukea suoraan bug-trackerin kautta. Itse olen saanut suoran Ceph-päivityksen Canonicalin kehitystiimiläiseltä alle vuorokaudessa (ilman kustannuksia korjauksesta). Tarvitsi vain kyetä osoittamaan missä koodivirhe oli.

Tarinassa aiemmin tapahtunutta: Vaultstack-klusterista yksi palvelin tipahti automaattisesti pois käytöstä laitteistovian takia. Palvelimen vikatilannetta selvitettiin ja löydettiin selkeästi vikaantunut muistikampa. Käytännössä kone ei pysynyt pystyssä muutamaa minuuttia pidempään Memtest86-testiohjelmaa ajettaessa ja hardware logitti runsaasti ECC-virheitä. Kyseinen muistikampa vaihdettiin ehjään ja koneella ajettiin useiden päivien ajan muistitestiä sen varmistamiseksi, että kyseessä oli varmasti ainoa viallinen muistikampa.

Tiedossa oli, että palvelimen liittäminen takaisin klusteriin lisää käytössä olevia levyresursseja, jolloin seurauksena on datan tasapainotus koko klusterissa, siten että uudet resurssit tulevat tasa-arvoisesti käyttöön entisten rinnalle. Asiakasnäkökulmasta tuo toimenpide on täysin läpinäkyvä.

Lisäsimme muutamia kuukausia sitten useita uusia palvelimia klusteriin, mukaan lukien tuo yksi, jolta löydettiin vikaantunut muistikampa. Tuo lisäystoimenpide tapahtui ongelmitta.

Vastaavasti vikaantuneita HDD-levyjä vaihdetaan noin 2-4 viikon välein, eikä tuostakaan koidu olennaista haittaa klusterin toiminnalle. Ceph on hyvin älykäs levyjen hajoamisen osalta. Klusteri rakentaa datan varmistustason aina ennalleen ehjille levyille heti levyn vikaantumisen jälkeen. Siten varsinaisilla vaihto-operaatioilla ei ole kiirettä.

Vastaavasti järjestelmä sallii sen, että alustapalvelimia voidaan käynnistää uudelleen päivitysten takia ilman että järjestelmän toiminta häiriintyy.

Koska palvelimen palauttaminen klusteriin vastasi aiemmin suoritettuja toimenpiteitä, joissa ei useilla toistokerroilla ollut havaittu mitään ongelmaa, palvelimen liittämisestä ei odotettu koituvan mitään ongelmia.


Yksi Ceph-järjestelmän perusyksiköistä on OSD, käytännössä tuo vastaa yhtä kiintolevyä ja sen klusteriin liittämiseksi tarvittavaa sovellusta. Järjestelmässä on kymmenittäin levyjä ja OSD:itä. Nämä muodostavat levytilaa tarjoavia pooleja. Kukin pooli määrittelee sen, millä varmuustasolla sinne tallennettu data säilytetään. Käytännössä meillä on käytössä replika pooleja 3n varmennuksella ja erasure-pooleja 4n+2k varmennuksella. Eli käytännössä kaikki data on vielä käytettävissä, vaikka kaksi laitteistoa hajoaisi. Ceph on konfiguroitu siten, että kaikki replika- tai erasure-code -poolin osat sijaitsevat erillisillä fyysisillä palvelimilla. Siten esimerkiksi yksittäisen palvelimen bootatessa järjestelmässä on vielä redundanssia olemassa.

Tilastotiede puolsi ongelmattomuutta, sattuma ei. Kun palvelin käynnistyi, sillä olevat OSD:t liittyivät klusteriin ja järjestelmä aloitti datan tasapainotuksen.

Hyvin nopeasti liittymisen jälkeen, klusterin valvonta havaitsi, että osa OSD:istä tipahti pois käytöstä.

Ensimmäinen reaktio ja arvio oli, voisiko tuo johtua siitä, että rebuild kulutti alustaresursseja poikkeuksellisen rivakasti, minkä seurauksena OSD:t timeouttasivat klusterin valvonnalle (Cephin oma sisäinen valvonta tapahtuu erittäin nopealla vasteella, sekunnin murto-osissa, kyse on levyjärjestelmän toiminnalle kriittisestä toimenpiteestä). Valvontanäkymä oli villiä katsottavaa, OSD:t hyppivät up/down tilojen välillä hyvin vauhdikkaasti.

Samaan aikaan klusterin tilatieto ilmoittaa järjestelmän synkronoinnin/redundanssin palautuksen tapahtuvan hurjalla vauhdilla ”recovery: 19 GiB/s, 851 keys/s, 3.16 kobjects/s”. Tietoliikenteessä tyypillisemmin käytettyinä megabitteinä nopeus on siten noin 163.000 megabittiä sekunnissa. Käytännössä tuo alleviivaa sitä, että kaikki osallistuvat laitteet rakentavat tietoa jatkuvasti uusiksi keskenään. Yksittäinen palvelinlaitteisto on liitetty järjestelmään 2×25 gigabittiä (25.000 megabittiä) liitynnöillä, joten yksittäiseen palvelimeen kohdistuva liikenne rajoittuisi tuohon.

Asiakaspalvelinten levytoiminnot kokevat hitautta tai estymistä, koska taustajärjestelmän näkökulmasta tilanne sen osalta, ovatko datan tarjoilemiseksi tarvittavat taustalevyt käytettävissä muuttuu useita kertoja sekunnissa.

Luonnollinen tarkistuskohde oli katsoa, onko vika siinä, että kukin OSD on käynnissä, mutta ei ehdi vastaamaan valvovalle monitorille. Ensimmäisenä pistokoetarkastus systemctl-komennolla tuki tuota teoriaa, servicet olivat olleet käynnissä kuukausia. Tämä johti tutkintaa hetken harhaan. Todellisuudessa systemctl oli tavallaan väärässä, sen valvoma prosessi oli käynnissä, mutta seuraavalla tasolla olevat prosessit kaatuilivat nopealla tahdilla. Tuon saattoi todistaa ps:llä prosessilistalla sekä oikeaa systemd:n journalia seuraamalla.


Tilanne oli hämmentävä: Miten ennenkin klusterissa olleen laitteen palauttaminen käyttöön saattoi aiheuttaa toistuvaa ohjelmiston kaatumissa kaikilla muilla klusterin jäsenillä? Ceph aikaleimoittaa kaikki tapahtumat ja tallentaa dataan mukaan tarkistussumman, joten ei ollut mahdollista, että ns. ”vanhan datan” liittäminen mukaan klusteriin voisi aiheuttaa ongelmia. Järjestelmä ei suostu käyttämään vanhentunutta tai rikkinäistä dataa. Järjestelmä myös käy jatkuvasti läpi tallennettua dataa ns. bit-rot -ilmiön välttämiseksi. Vaikka sinä et olisi lukenut dataa kahteen vuoteen, järjestelmä on lukenut sen, ja tarkistanut että data vastaa tarkistussummaa, lukuisia kertoja.

Eristämme uuden palvelimen pois klusterista, jotta tilanne saadaan vakautumaan. Suurin osa klusterin datasta palautuu välittömästi takaisin käyttöön. OSD:iden villi hyppiminen up/down -tilojen välillä on kuitenkin aiheuttanut uuden ongelman: Järjestelmä sallii datan käytön, kunhan minimimäärä OSD:itä on läsnä. Seurauksena mukaan liitetty palvelin on osallistunut klusteriin ja osa ongelman aikana muuttuneesta datasta on tallennettu siten, että datan käyttämiseksi myös kyseisen palvelimen OSD:iden täytyy olla mukana klusterissa.

Datankäyttö estyy monelta virtuaalipalvelimelta, koska järjestelmä pysäyttää pääsyn dataan, ellei riittävää määrää ehjiä kopioita ole käytettävissä. Hyvänä puolena, käytännössä kaikki nykyaikaiset käyttöjärjestelmät osaavat vaatia kirjoituskuittauksen alustalta oikea-aikaisesti, mikä huolehtii siitä, että Ceph-klusterin päällä toimivat virtuaalipalvelinten levyjärjestelmät ovat olennaisilta osin ehjiä, kunhan ne palauttavat journalista uusimmat muutokset. Sama pätee oikein toimiviin tietokantoihin, muutokset joko ovat kannassa tai eivät ole. Esim. oikein transaktioita käyttävät järjestelmät eivät ole voineet kuitata asiakkaalle tilausta onnistuneeksi ja sitten hävittää sitä. (Ei puututa huonosti koodattuihin järjestelmiin, niitähän ei pitäisi käyttää, eihän…)

Sivuhuomiona: ”Kello käy, kello käy, asiakaspainetta tulee vikapäivystykseen.” Tosin kuuleman mukaan erittäin ymmärtäväistä ja rauhallista. Olen hieman yllättynyt. Tässä vaiheessa oman kiireen on kuitenkin pitänyt loppua jo vian alkaessa. Yllättävä vika tapahtui, asiakasdata kyseessä. Kiireen tai paineen takia tilannetta ei saa pahentaa.

Logeista päätellen muutamilla koneilla ilmeni RDMA-virheitä. Rajusti yksinkertaistettuna RDMA sallii palvelinten käyttää muiden palvelimien muistia verkon yli lähes kuin omaa muistiaan.

Olisiko vikana muutos RDMA-kirjastoissa? Epätodennäköistä, vaikka palvelin oli poissa ollessaan missannutkin yhden päivityskierroksen. Klusteriin on ajettu käytönaikaisia päivityksiä useita kertoja ja päivitysten yhteydessä eri palvelimilla on eri kernel- ja ohjelmistokirjastoversioita. Eikä noistakaan ole koitunut ongelmia.


Päätelmät: koska vika alkoi palvelimen palauttamisesta, kyseisen palvelimen täytyy olla vähintään ”osasyyllinen” vikaan. OSD:iden restarttailu johtunee siitä, että kun niiden välisistä peering-yhteyksistä riittävän moni päätyy odottamaan yhteyden muodostumista, prosessi jumiutuu ja käynnistetään uudelleen.

Päätän testata RDMA-yhteyksiä muille koneille.

Nopea havainto on, että rdma-ping toimii klusteriin palautetulta koneelta vain osalla muita koneita.

Molemmat levyklusteriin liittyvät verkkoliitynnät ovat up-tilassa sekä kytkimen että palvelimen näkökulmasta. Liikenne ei kuitenkaan kulje oikein, joten johtopäätös on, että toisen linkin täytyy olla tilatiedosta huolimatta rikki (”hauskaa” sinänsä, että kyseessä on lacp-varmennusprotokollaa ajava linkki, joten tuon protokollan pitäisi huomata vika ja pistää linkki alas). Nopea tcpdump-varmentaa, kumpi linkeistä on rikki. Ajan portin alas ja palautan palvelimen OSD:t tuotantoon.

Osa OSD:istä palautuu up-tilaan ja hyppimistä ei näytä tapahtuvan. Muutama ei näytä palautuvan. Ne pitää käydä korjaamassa manuaalisesti, koska systemd on vihdoin havainnut ongelman ja yrittänyt uudelleenkäynnistää prosessia niin kauan, että restart-limit on pysäyttänyt uudelleenkäynnistyskierteen. Resetointi failcountille ja prosessin käynnistys korjaa tilanteen kyseisten osalta.

Vihdoin ollaan tilanteessa, jossa kaikki OSD:t ovat tilassa ”up”.

Asiakasvirtuaalien tuotanto palautuu normaaliksi. Järjestelmän vahvan tapahtumien aikaleimauksen ja tarkistussummien ansiosta, voimme myös luottaa siihen, että käytössä oleva data on aidosti ehjää sekä tuotannossa on aidosti viimeksi muutettu data.

Suuri osa asiakaspalvelimista selvisi häiriöstä siten, että toiminta jatkoi levyn palauduttua käyttöön. Osa varsinkin hyvin aktiivisesti levyä käyttävistä palvelimista vaatii uudelleenkäynnistyksen. Suosittelemme tekemään uudelleenkäynnistyksen joka tapauksessa, suorittamaan levytarkastuksen sekä ajamaan tietokannoille tarkastukset. Vaikka taustajärjestelmässä tiedon eheys on taattu (sen tiedon osalta, joka virtuaalipalvelinten käyttöjärjestelmille on kuitattu levylle kirjoitetuksi), se ei takaa sitä, etteikö virtuaalipalvelimen puolella jokin ohjelmisto voisi olla jumissa pitkän levynkäytön eston johdosta.

Merkitsemme ongelmallisen palvelimen OSD:t poistettavaksi datakäytöstä ja odotamme, että järjestelmä rakentaa redundanssin ennalleen, eli varmistaa että kaikesta datasta on joko ylimääräiset kaksi replikaa tai erasure code-unittia.

Datan uudelleenrakennuksen jälkeen irrotimme ongelman aiheuttaneen palvelimen levyklusterista sekä Vaultstackin laskentakapasiteettipoolista. Ongelman ilmenemismuoto ja seuranneen kaskadihäiriön syyt ja seuraukset ovat tiedossa. Vian juurisyyn aiheuttaja on kuitenkin vielä selvitettävä, miten lacp-valvottu linkki onnistui olemaan up-tilassa ja olemaan välittämättä RDMA-liikennettä.

”Monimutkaiset järjestelmät rikkoutuvat monimutkaisilla tavoilla”; mutta tilanne on mielestäni melko ”arkipäiväinen” sen osalta, että ainakin omalle kohdalleni osuvat vikatilanteet harvemmin lähtevät liikkeelle ilmiselvistä tai aiemmin koetuista asioista, jotka olisi ollut yksinkertaista välttää. Lisäksi tilannetta diagnosoidessa törmää ristiriitaiseen tilatietoon eri lähteistä. Noista pitää sitten omalla kokemuksella ja intuitiolla arvioida tilanne ja rakentaa ratkaisu.


Esitän nöyrimmät kiitokset Cephin kehittäjätiimille. Vaikka joku voisi väittää, että tuokin asia olisi pitänyt selvittää ilman syntynyttä katkoa, minä olen eri mieltä. Cephin kehittäjätiimi tuottaa ohjelmistoa, eikä rautaa. Nyt tapahtunut virhe vaikuttaisi olleen itse Ceph-ohjelmiston ulkopuolella. Ohjelmisto ja sen muodostama klusteri toimi parhaansa mukaan yrittäen käynnistää jumittuneita osiaan sekä käytti kulloinkin käytettävissä olevia resursseja palveluiden tuottamiseen. Tulevaisuudessa tämäkin virhe voidaan varmasti selvittää ilman katkosta, mutta emme elä täydellisessä maailmassa. Ongelmia pitää ensin kokea niiden havaitsemiseksi ja sittemmin korjaamiseksi.

Tässä tapauksessa ongelmatilanne oli sellainen, että tilanteen ratkaisemiseen tarvittiin ylläpitäjän harkintaa. Monessa muussa tilanteessa ohjelmiston toimet ovat hoitaneet tilanteen kuntoon ennen kuin ylläpitäjä on ehtinyt tutkimaan tilannetta. Ja tässäkin tilanteessa tärkein asia hoitui: järjestelmä kykeni huolehtimaan siitä, että sekavassa tilanteessakin kaikki data käsiteltiin siten, että sen eheys säilyi ja tallennettua dataa ei hävinnyt.

Olen nähnyt aika monta järjestelmää, jotka olisivat pienemmänkin vian kohdalla romuttaneet kaiken tallennetun datan ja edellyttäneet asiakasjärjestelmien palauttamista varmuuskopioista. Ja osa niistä olisi vielä antanut virtuaalipalvelinten jatkaa levynkäyttöä senkin jälkeen, kun eheys on menetetty. Moni järjestelmä myös toimii täydellisesti ensimmäiseen vikaan asti. Sen jälkeen se ei enää toimi ennen uudelleenluontia.

Minä pidän järjestelmistä, jotka voi tarvittaessa vaikka purkaa osatekijöihinsä, koota sen jälkeen ja jatkaa käyttöä. Ceph on toistuvasti osoittanut olevansa tuollainen järjestelmä.

Mielestäni Ceph-todisti jälleen kerran luotettavuutensa datan säilyttämisessä.

Timo Nieminen
Teknologia- ja talousjohtaja