Tietolinja
01/2003

Sannin oppivuodet 

kokemuksia Sun E10000-palvelimesta ja Voyager-kirjastojärjestelmästä yliopistokirjastojen Linnea2-konsortiossa

Juha Hakala
Helsingin yliopiston kirjasto

URN:NBN:fi-fe20021559

Koska täydellisyyttä ei ole olemassakaan, myös uusi kirjastojärjestelmämme menee joskus kokonaan mykäksi tai toimii kiusallisen hitaasti. Moni lienee tuolloin noitunut Voyageria ja mahdollisesti jopa toivonut vanhan VTLS-sovelluksen paluuta; aikahan kultaa kaikki muistot.

Voyager ei kuitenkaan läheskään aina ole vikapää ongelmiin. Tässä artikkelissa kerrotaan käytännön kokemuksen pohjalta esimerkkejä siitä, mitä voi mennä pieleen, Voyagerissa ja muualla. Kerron myös miten hankaluuksista on otettu opiksi.

Rauta

Yliopistokirjastojen yhteinen Sanni-palvelin, vähemmän tuttavallisesti Sun E10000, varustettiin niin, että kaikki mahdolliset osat on kahdennettu. Yhden levyn, levyohjaimen, tai muun rikkoutuvan osan vikaantumisen ei periaatteessa pitäisi aiheuttaa mitään ongelmia.

Käytännössä järjestelmään tuli kuitenkin yksi Akilleen kantapää: systeemin (käyttöjärjestelmän) käytössä olevat levyt. Sun lisäsi aivan palvelimen hankintaprosessin loppuvaiheessa koneelle kymmenen 9 GB levyä, kaksi kuhunkin koneen viidestä loogisesta osasta eli domainista. Levyt peilattiin niin ettei levyrikoista koituisi mitään ongelmia.

Kun Sannin tuotantokäyttö alkoi, havaittiin ettei Solaris-käyttöjärjestelmällä ollut tarpeeksi tilaa käyttäjien muistiin tallentamille sivuille. Endeavor poisti tällöin systeemilevyjen peilauksen swap-eli heittovaihtomuistin tarvitseman tallennustilan osalta. Tämä takasi swap-tilan riittävyyden, mutta aiheutti sen, että kun jompikumpi jonkin domainin systeemilevyistä hajosi, joidenkin käyttäjien istunnot joutuivat jokseenkin patologiseen tilaan muistisivujen kadottua levyltä

Tämä ongelma on poistettu kasvattamalla systeemilevyjen kokoa 18 gigatavuun, ja palauttamalla swap-tilan peilaus. Muutoksen yhteydessä poistettiin domain 1:ssa swap-tila tietokantojen käytössä olevilta levyiltä. Normaalitilanteessa 18 GB on riittänyt hyvin domainien swap-tarpeisiin. Domain 1:een on myöhemmin asennettu vielä lisää 9 GB peilattua levyä, mikä maksimoi varmuuden tämän ahkerimmin käytetyn domainin osalta.

Systeemilevyjen lisäksi Sannista on rikkoutunut silloin tällöin tietokantojen käytössä olevia levyjä. Nämä ongelmat eivät kuitenkaan ole näkyneet käyttäjille mitenkään, koska levyt on peilattu; jokaisen levyn sisällöstä on identtinen kopio toisella levyllä. Sen sijaan levyt ja Sannin keskusyksikön yhdistävän kuituväylän rikkoutuminen on vakava ongelma domaineissa 3-5, koska näissä väylää ei ole kahdennettu. Kahden ensimmäisen vuoden aikana väylärikkoja on sattunut vain kerran, domainissa 5. Koska väylässä ei ole liikkuvia osia sen vikaantumisherkkyys ei ole suuri, mutta siitä huolimatta Sannin seuraaja kannattaisi suunnitella niin, että kaikki väylät on kahdennettu.

Sannin rautaongelmista pahin oli joulukuussa 2002 sattunut nelosdomainin yhden prosessorin paniikkihäiriö, joka aiheutti koko domainin kaatumisen. CSC:n mukaan näitä ongelmia sattuu suurissa palvelimissa satunnaisesti, ja ne ovat yleensä kertaluonteisia. Ongelman uusiintuessa prosessori vaihdetaan. Tässä tapauksessa kone kaatui niin äkillisesti, ettei Solaris ennättänyt tallentaa mitään tietoa ongelmasta. Tästä huolimatta Oracle ja Voyager hoitivat tilanteen mallikelpoisesti; tietokannat heräsivät henkiin ongelmitta ja stabiilissa tilassa, eikä mitään tallennettua dataa hävinnyt. Tämä kertoo Oraclen ja kirjastojärjestelmämme vakaudesta. 

Olemme seuranneet tarkoin Sannin kapasiteetin riittävyyttä. Konehan pyrittiin mitoittamaan konservatiivisesti, ja vaikuttaa siltä että useimpien domainien CPU-teho riittää mainiosti normaalitilanteessa. Poikkeustilanteissa järjestelmä on valitettavasti ollut tilapäisesti hyvin hidas. Domain 3:n osalta kapasiteetin riittävyyttä on aika ajoin epäilty, ja esimerkiksi kuluvan syksyn mittaan oli yksi viikon parin mittainen paha ongelmajakso ennen systeemilevyn rikkoutumista. Tätä jaksoa lukuun ottamatta Sanni on kuitenkin toiminut useimmissa tuon domainin kirjastoissa hyvin, eikä laitteistokapasiteetin laajentaminen ole suunnitteilla.

Kahdessa kolmosdomainin kirjastoista on esiintynyt etenkin luetteloitaessa yhteyksien katkeilua; ongelman syy oli todennäköisesti Z39.50-konfigurointi. Kun hakutermien katkaisu oikealta määriteltiin pakolliseksi kaikissa etätietokannoissa, ne tietokannat jotka eivät tukeneet hakutermien katkaisua eivät toimineet kunnolla. Näiden Z-istuntojen epävakaus kaatoi lopulta kaikki luettelointiclientit. Ongelma korjautui sillä että hakutermien katkaisun pakollisuus poistettiin ao. kirjastojen Voyager-määrityksistä.

Sannin lisäksi CSC:n vierihoidossa ovat WWW-edustakoneena käytetty Sun Netra-palvelimien klusteri sekä sitä ohjaava Alteon-kytkin. Netrojen reistailu ei juuri näy käyttäjille, koska yhden koneen hajotessa toiset hoitavat työt. Heikosti käy vain niille, jotka käyttivät juuri sitä Netraa joka levisi, ja hekin voivat aloittaa istunnon alusta. Valitettavasti Alteon on ollut heikompi lenkki kuin Netra-palvelimet, ja kytkimen kaatuminen on ollut turhan yleinen syy WebVoyage-yhteyden katkeamiseen. Jatkossa pitänee harkita kytkimen kahdentamista tai muuta menettelyä jolla varmistetaan se, ettei Alteonin reistailu vaikuta käytettävyyteen.

CSC:n laiteympäristöön kuuluu myös varmistusten tekoon käytetty backup-laite sekä palomuureja ja reitittimiä, jotka on käyttövarmuuden maksimoimiseksi kahdennettu. Backup-koneen reistailu voi aiheuttaa - esimerkiksi joulukuun alussa - sen, että varmistukset eivät mene läpi ja Voyager pitää herätellä henkiin erikseen. Reititintason ongelmat eivät tietääkseni ole koskaan näkyneet Voyagerin käyttäjille asti, lukuun ottamatta sitä kertaa jolloin konehuoneessa asennuksia tekevät sähkömiehet katkaisivat sähköt väärästä paikasta väärään aikaan. En usko että tätä ongelmaa voitaisiin eliminoida kokonaan vaihtamalla sähkömiehiä, erehtyminen kun on inhimillistä.

FUNETin ja yliopistojen paikallisverkkojen luotettavuus on viime vuosina jatkuvasti parantunut. Minun tietojeni mukaan FUNET ei ole Voyager-aikana aiheuttanut ainuttakaan laajaa käyttökatkoa; tämä johtunee muun muassa siitä, että koko verkko on kahdennettu. Yksittäisillä yliopistoilla on ollut satunnaisesti paikallisia ongelmia, mutta esimerkiksi Helsingin yliopistossa nämä vaikeudet, jotka takavuosina olivat kiusallisen yleisiä, ovat kadonneet kokonaan. Tämä kertoo paitsi laitteistojen ja ohjelmistojen kehittymisestä, myös siitä, että FUNETin ja yliopistoverkkojen ylläpitäjät hoitavat työnsä erinomaisesti, mistä lämmin kiitos kaikille tähän työhön osallistuville. 

Varusohjelmistot

Voyagerin ohella Linnea-ympäristössä käytetään melkoista määrää ohjelmia, alkaen Solaris-käyttöjärjestelmästä ja Oracle-tietokantasovelluksesta. Kaikissa näissä ohjelmissa voi tietenkin olla bugeja, jotka voivat näkyä kiusallisesti.

Solaris ei ollut aiheuttanut mitään ongelmia, mutta kun syyskuussa 2002 asennettiin Solaris 8:n patch 15, Oracle alkoi toisinaan sekoilla yrittäessään kirjoittaa levylle. Pääasiallinen syyllinen näihin ongelmiin oli virheellisen WebVoyage-konfiguroinnin tuloksena syntynyt väärä linkki signum-tietoihin (tästä lisää alla), mutta saimme silti käskyn päivittää Solaris nopeasti patch 16:een, ja tällä patch-tasolla ongelmia ei ole ilmennyt, sen jälkeen kun WebVoyage-konfiguraatio korjattiin. Kollegani Jose Borbinha Portugalin kansalliskirjastosta kertoi että heidän Horizon-sovelluksensa, joka Voyagerin tavoin käyttää Oraclea, oli kaatunut ensimmäisen kerran kahteen vuoteen sen jälkeen kun Solaris patch 15 oli asennettu, joten on mahdollista, että tässä Solaris-versiossa oli levyI/O:hon liittyvä ongelma.

Varusohjelmista pahin bugi on tavattu ssh-tietoturvasovelluksessa. Tietyissä olosuhteissa saattoi käydä niin, että ssh-putken yli avattu, tiedostojen siirtoon tarkoitettu sftp-istunto jäi roikkumaan Sanniin ja söi kaiken CPU-kapasiteetin, minkä se sai yhdestä prosessorista käyttöönsä. Pienissä domaineissa pari tämmöistä CPU-ahmattia ruuhka-aikana hidasti Voyagerin toimintaa jo silmin nähden, ja 3-4 ongelmaistunnosta syntyi jo suuria vaikeuksia.

Ssh-sovelluksen uudessa versiossa tämä kiusallinen ongelma on poistunut. Sanni kuitenkin jumiutuu edelleen satunnaisesti, koska vuoden 2002 keväästä alkaen vasteaikaongelmia on toisinaan aiheuttanut se, että Oracle on villiintynyt ja alkanut generoida Sannin jossakin domainissa nopeaan tahtiin uusia prosesseja. Tämä täyttää prosessien määrän kasvun myötä swap-muistin nopeasti, ja sitä kautta jumittaa koneen. Ongelma on yleensä saatu aisoihin vain pudottamalla Oracle alas ja käynnistämällä se uudelleen. Emme ole täysin varmoja onko vika Oraclessa vai Voyagerissa - todennäköisesti jälkimmäisessä -, mutta vastuu ongelman ratkaisemisesta on varmasti Endeavorilla. Odotamme edelleen tyydyttävää vastausta; niin kauan kuin sitä ei ole saatu, CSC:llä on vastuu siitä että nämä ongelmatilanteet hoidetaan nopeasti.

Voyager

Edellä mainitun prosessimyrskyn ohella vasteaikaongelmia on toisinaan syntynyt sen vuoksi, että Voyagerin sanahaun keysrv-prosessit villiintyvät, ja kuluttavat kaiken CPU-ajan jonka saavat yhdeltä prosessorilta käyttöönsä. Neljä tällaista prosessia samaan aikaan samassa domainissa on varma resepti pahoille ongelmille; ainakin domain 5:ssä muistan nähneeni tämmöisen tilanteen. Nämä villiprosessit ovat hankalia, koska ne eivät katkea silloin kun tietokanta ajetaan alas - Voyagerin indeksit kun eivät ole Oraclessa. Siksi prosessi voi periaatteessa ahmia CPU:ta päiväkausia ellei sitä katkaista. CSC on kehittänyt välineitä näiden prosessien automaattiseen havaitsemiseen ja katkaisuun, mikä on vähentänyt näiden ongelmien määrää.

Me voimme itsekin vaikuttaa Voyagerin aiheuttamaan kuormaan paljon. Tietokantojen indeksit kannattaa luoda uudelleen riittävän usein, mikä tarkoittaa isoissa tietokannoissa tiheää päivitysaikataulua. Jos keyword regenin tekemistä lykätään, sekä uusien tietueiden indeksointi että sanahaku hidastuvat, ja koneen kuormitus kasvaa. Tietokantapalveluissa on todettu, että jo kauan ennen Endeavorin ilmoittamia raja-arvoja eräpäivitykset kantaan hidastuvat pahoin; emme ole täysin varmoja siitä, johtuuko tämä paikallisista erikoispiirteistä (suomen kielestä sijamuotoineen syntyy hyvin järeä indeksi), vai onko Endeavorin mitoituksessa vikaa. Uskon itse että suomenkielisen aineiston käsittely vaatii Endeavorin suosituksia tiuhempaa regenien tekoa. Lindassa on syksyn mittaan ajettu indeksien päivitys joka toinen yö; muina öinä kantaan ajetaan kirjastojen välivaiheen aineistoa, noin 15.000 tietuetta vuorokaudessa. Ellei regeniä tehdä, loadit hidastuvat nopeasti ja dramaattisesti.

Voyager ja muutkin kirjastojärjestelmät on suunniteltu niin, että päivitysten teko on paljon raskaampaa kuin tiedonhaku. Esimerkiksi Kongressin kirjaston Voyager-sovelluksen vasteaikaongelmien aiheuttaja on kirjaston 1000 luetteloijan aiheuttama kuorma, ei tuhansien tiedon hakijoiden kannassa aiheuttama kuormitus. Siksi kirjastojen kannattaa pitää hyvää huolta tietokantojensa indekseistä.

Keyword regenien teko pitää mahdollisuuksien mukaan automatisoida niin, että CSC voi tehdä niitä aina kun tarvitaan ilman mainittavaa henkilötyön tarvetta. Tässä työssä ollaan päästy jo varsin pitkälle.

Inhimillinen erehdys

Vain pieni osa Voyagerin käytön estävistä ongelmista kuuluu tähän kategoriaan; esimerkiksi Linnea1:ssä näitä ongelmia on ollut syksyn 2002 aikana kolme, kun ohjelmisto-ongelmia on ollut neljä. CSC:n väki ja systeeminhoitajat ovat siis hyvin tehtäviensä tasalla. Eivätkä kaikki tämän ryhmän ongelmat välttämättä ole systeeminhoitajien syytä. Jokainen, joka voi ajaa raportteja tietokannasta ODBC-ajureiden välityksellä, voi vahingossa laittaa ajoon raportin joka raskaudellaan aiheuttaa vasteaikaongelmia. Kenties olisi syytä rajata raporttien ajamisoikeuksia vain niille jotka on asianmukaisesti koulutettu.

VTLS:ssä sekä inhimillisiä erehdyksiä että ohjelmistovikoja esiintyi hyvin harvoin. Ohjelmiston vakaus johtui muun muassa siitä, että se oli toiminnoiltaan yksinkertainen. Jos jätti systeemin omat parametrit rauhaan, ohjelmaa oli vaikea järkyttää toimintakyvyttömäksi. Voyagerissa parametrien kirjo on paljon monipuolisempi, ja tietämättömyydestä maksettava hinta vastaavasti korkeampi kuin VTLS:ssä. Voidaan myös väittää, että HP3000 ja TurboImage olivat kirjastojärjestelmälle pelkistetympi ja vakaampi alusta kuin Sun-palvelin ja Oracle. Tästä on kuitenkaan vaikea esittää mitään täsmällisiä tuloksia.

Yksi kriittisistä Voyager-parametreista on Web-istunnon timeout. Systeeminhoitajien on käsketty määritellä näille istunnoille timeoutiksi viisi minuuttia, toisin sanoen Web-käyttäjän yhteys tietokantaan katkeaa viidessä minuutissa ellei käyttäjä tee mitään. Koska WebVoyage-istuntoja on suurissa kirjastoissa hyvin paljon ja ne ovat aktiivisia vain muutaman minuutin, viiden minuutin timeout lisää prosessien määrää muutaman kymmenen prosenttia. Järjestelmälle nämä ylimääräiset passiiviset istunnot eivät ole ongelma, kunhan muistisivuille varattua swap-tilaa on riittämiin.

Jos timeout-parametrin arvoa pidennetään viidestä minuutista esimerkiksi tuntiin, prosessien määrä moninkertaistuu, koska 5 + 5 minuutin asemesta istuntojen keskimääräinen pituus nouseekin 5 + 60 minuuttiin. Kun domain 1:ssä timeoutiksi määriteltiin yhdessä tietokannassa vahingossa yksi tunti, prosessien määrä nousi jyrkästi noin 40 minuutin ajan, kunnes domainin swap-tila loppui. Solaris-käyttöjärjestelmä ei valitettavasti osaa käsitellä tällaista tilannetta elegantisti, vaan Solaris hidastuu hidastumistaan, kunnes se on lopulta pakko kaataa.

Pienessä tietokannassa timeoutin pidentämisen vaikutus ei välttämättä olisi kovin dramaattinen, mutta käyttäjien yhdenvertaisen kohtelun nimissä timeout on syytä pitää kaikkialla samana. Sitä paitsi Voyagerin säädöillä ei jatkossa välttämättä ole suurta merkitystä; vuonna 2003 käyttöön otettava portaalisovellus ratkaisee ainakin osittain timeout-ongelman; siinä istunnon tiedot kootaan portaalisovellukseen, joka osaa jatkaa "istuntoa" oikeasta kohdasta vaikka kohdetietokanta olisi ajat sitten katkaissut session.

Timeoutin kaltaisen selkeän muuttujan lisäksi Voyagerissa on vaikeammin havaittavia sudenkuoppia. Yhteen niistä törmättiin Lindassa syyskuussa 2002, kun varastotietojen näyttöjen WebVoyage-konfiguraatio yhtenäistettiin kaikissa Linnea-tietokannoissa. Tässä yhteydessä signum-tiedosta tuli linkki niteeseen. Kun käyttäjä sitten yritti kaivaa nidetiedot (joita ei ollut olemassa) esille, istunto jäi jumiin. Kun näitä istuntoja sitten kertyi riittämiin, Oracle kaatui erään tietokantataulun täytyttyä. Ongelman syyn selvittämiseen kului sekä meiltä että Endeavorilta runsaasti aikaa, koska epäilimme syylliseksi välivaiheen aineistojen loadeja. Tarinan opetus on se, että kaikki Voyager-parametrointiin tehtävät muutokset ja niiden ajankohdat on dokumentoitava. Lisäksi vanha konfiguraatio on syytä tallentaa jonnekin.

Kun Voyager ajetaan alas varmistuksia varten, tavalliset istunnot pätkäistään armotta poikki. Mutta raporttien tekoa varten suoraan tietokantaan otettua ODBC-yhteyttä ei ole tapettu noin vain. Tavallinen seuraus tästä on ollut se, että varmistuksia ei saada ao. tietokannasta, koska Oraclea ei ole saatu ajetuksi alas. Normaalisti CSC:n päivystäjä on saanut tiedon näistä ongelmista, ja asiat on hoidettu normaalille tolalle ennen kirjastojen avaamista.

Toisinaan on käynyt niin, ettei CSC:n hälytysjärjestelmä ei ole toiminut, ja tällöin aamuvirkut ovat tavanneet tokkuraisen Voyagerin. Jos mitään poikkeavaa ei ole tapahtunut, CSC on näissä tilanteissa saanut Voyagerin virkoamaan nopeasti. Ongelmatilanteiden vähentämiseksi Endeavorilta pyydettiin skripti, joka ajaa Oraclen alas silloinkin kun tietokantaan on avoin ODBC-istunto, koska Oracle ei kokemusten mukaan jää rajumpienkaan alasajojen jälkeen epästabiiliin tilaan. Endeavorilta saatu uusi sovelluksen sulkemisskripti otettiin käyttöön lokakuun lopulla, eikä sen soveltaminen ole aiheuttanut vaikeuksia.

Lopuksi

CSC on rakentanut välineet, joiden avulla saamme tiedon Sanni-palvelimen käytettävyydestä. Tilastot osoittavat että käytettävyys on ollut hyvin korkea, yli 99.99 %, kuten Sun on luvannutkin. Voyagerin käytettävyys on ollut alhaisempi, ja siitä meillä ei toistaiseksi ole tilastoja. CSC:n tarkoitus on rakentaa ohjelma, joka tekisi Voyager-tietokannoista hakuja aika ajoin; tällä tavoin saisimme tilastot ainakin hakukäytön käytettävyydestä. Muiden modulien osalta käytettävyyden arviointi on vaikeampaa.

Eniten julkisuutta saanut Voyager-ongelma oli Helkan loadin yhteydessä tapahtunut harvinainen virhe, jonka vuoksi tietokannan tekijähakemisto ei ollut käytettävissä. Lainauskäytön alettua tämä Endeavorin erhe aiheutti koko domain 1:n jumittumisen, koska jokainen Helkan tekijähaku luki tietokannan kaikki 1.5 miljoonaa MARC-tietuetta peräkkäislukuna läpi. Tämä vaati pari minuuttia silloinkin kun oli tietokannassa yksin. Kun käyttäjiä oli kymmeniä, tulos oli ikävä: levyI/O meni täysin tukkoon. Vian paikallistaminen ja korjaaminen vei neljä päivää; samana aamuna kun Hesari uutisoi vaikeuksista, tietokanta oli jo kunnossa. Kunpa ongelma olisi korjattu päivää aikaisemmin…

Edellä kuvatun probleeman tavoin useimmat hankaluuksistamme on kyetty ratkaisemaan kohtuullisen nopeasti, oli niiden syy sitten Voyagerissa tai jossakin muualla. Ongelmanratkontaa helpottaa avoin mieli; ei pitäisi olla ennakkoon liian varma sylttytehtaan sijainnista. Ei myöskään pitäisi syyllistää Endeavoria aina kun näyttöluettelon tai yhteisluettelon käyttö tökkii.

Vaikka useita ongelmia on kyetty eliminoimaan kokonaan tai ainakin osittain, on varmaa että sataprosenttiseen käytettävyyteen me emme pääse. Nykyaikainen kirjastojärjestelmä palvelimineen on monimutkainen systeemi, joka muuttuu koko ajan yhä monimutkaisemmaksi. Vastuu käytettävyyden parantamisesta on paitsi laitteisto- ja ohjelmistotoimittajilla joiden on testattava tuotteensa kunnolla, myös meillä käyttäjillä.