Tietolinja

Tietolinja
4/1999


PÄÄKIRJOITUS

ARTIKKELIT


Rautaisannos - perustietoja Linnea2:n palvelinratkaisusta

Juha Hakala


Tässä artikkelissa annetaan perustiedot Linnea2-verkon kirjastojen palvelinratkaisusta ja yhteisestä Sun E10000-palvelinkoneesta. Kerron myös lyhyesti FUNET-verkon rakenteesta ja kehityksestä sekä Voyager-ohjelmiston verkko-ominaisuuksista. Kaikki nämä tekijät yhdessä muodostavat sen perustan, jonka varaan keskitetty verkko voidaan turvallisin mielin rakentaa.

Aluksi

Linnea2-verkon kaikki 25 Voyager-tietokantaa viedään yhdelle palvelinkoneelle, jota ylläpitää CSC - Tieteellinen laskenta oy. Ratkaisu on maailmanlaajuisestikin ensimmäinen laatuaan; missään muualla eivät yliopistokirjastot ole sopineet yhteisestä tietokantapalvelimesta ja sen ylläpidon ulkoistamisesta kansallisella tasolla. Yhdysvalloissa on muutamissa osavaltioissa - esimerkiksi Georgiassa - jo rakennettu vastaavanlaisia verkkoja.

Palvelinhankinta perustui Voyager-sovelluksen sekä tarjolla olleiden laitteistovaihtoehtojen huolelliseen tekniseen analyysiin ja kustannusten arviointiin. Suomen erinomainen verkkoinfrastruktuuri sekä yliopistokirjastojen pitkä yhteistyöperinne olivat kumpikin välttämättömiä edellytyksiä yhteisen laitteiston valinnalle.

Uusi palvelinkone - Sun Enterprise 10000

Voyager-palvelinohjelma voidaan jakaa kolmeen osaan: tietokantaan, Voyager-sovellukseen (application module) sekä WWW-käyttöliittymäsovellukseen (Web Voyage). Nämä ohjelmistot voivat toimia joko samassa koneessa tai ne voidaan hajauttaa. Tietokantapalvelin ja sovelluspalvelin on sijoitettava lähelle toisiaan, käytännössä samaan lähiverkkoon. WWW-käyttöliittymää ajava palvelin voidaan hajasijoittaa Internet-yhteyden taakse, koska tiedonsiirto sen ja sovellusohjelmapalvelimen välillä on hyvin nopeaa.

Linnea-kirjastot ovat päättäneet hankkia yhteisen palvelimen tietokannoille ja sovellusohjelmille. WWW-käyttöliittymiä varten hankitaan erillisiä palvelinkoneita, joiden tekniikasta puhun lisää tuonnempana.

Yhteisen tietokantapalvelimen hankkiminen oli huolellisen analyysin tulos. Kolme eri vaihtoehtoa tutkittiin perusteellisesti: keskitetty yhden koneen malli, 3-5 palvelimen osittain keskitetty ratkaisu sekä nykyistä Linnea1-verkkoa vastaava hajautettu ratkaisu, jossa periaatteessa jokaisella kirjastolla on oma palvelin. Kustannuslaskelmissa otettiin huomioon laitteiston ostohinta, laitteistotoimittajalle viiden vuoden aikana maksettavat tuki- ja huoltomaksut sekä palvelimen ylläpitokustannukset.

Teknisessä ja kustannusvertailussa parhaaksi ratkaisuksi selvisi keskitetty järjestelmä. Keskittämällä säästetään pelkästään laitteistovalmistajalle maksettavissa tuki- ja huoltomaksuissa nykytilanteeseen verrattuna noin miljoona markkaa vuodessa, siitä huolimatta että tuen laatutasoa nostetaan. Myös palvelimien ylläpidossa saavutetaan merkittävä, arviolta noin 2-3 henkilötyövuoden säästö, kun koneiden määrä vähenee 17:stä yhteen. Tilasäästöjä ja sähkömaksujen alenemista emme valitettavasti pystyneet laskemaan, mutta nekin lienevät merkittävät.

Valintavaiheessa vertailtavina olivat Sunin palvelimet sekä IBM:n RS/60000-sarjan koneet. Suurin osa Voyager-kirjastoista, noin 90 %, käyttää Sun-palvelimia, mutta Linnean laitevalintaprosessissa molemmat toimittajavaihtoehdot olivat tasavertaisina mukana. Prosessin mittaan kummankin toimittajan koko laitteistoarsenaali pienimmästä suurimpaan tuli varsin tutuksi mukana olijoille.

Keskitetyssä vaihtoehdossa kilpakumppaneina olivat IBM RS/6000 SP- sekä Sun E10000-laitteet. Molemmat ovat vuonna 2000 valmistajiensa UNIX-malliston huippuja niin tehon kuin käyttövarmuudenkin osalta: nämä koneen ovat paitsi erittäin nopeita, myös hyvin luotettavia.

Varsinkin IBM:n SP-sarjan tietokoneista voidaan tehdä todella isoja - CSC:hen kesällä 2000 ostettu kansallinen superkoneemme on SP-kone, jossa jo näin alkajaisiksi on satoja prosessoreita, ja myöhemmin tuhansia. Linnean kaltaisessa kirjastoverkossa ei kuitenkaan toistaiseksi ole tarvetta massiiviseen laskentakapasiteettiin eikä palvelimen suurentamiseen satoihin tai jopa tuhansiin prosessoreihin asti. Ja jos tämmöinen tarve joskus 10-20 vuoden päästä tulee, laitteistosukupolvet ovat jo vaihtuneet, eikä vanhan palvelimen laajentaminen enää tulisi kyseeseen.

Yhteiseksi palvelimeksi valittiinkin Sun E10000, joka oli paitsi tekniseksi erinomainen valinta, myös edullisin tarjotuista vaihtoehdoista. Hinnan ja laadun ohella tätä valintaa puolsi se, että sekä kirjastojärjestelmätoimittajamme Endeavor että Oracle (Voyagerin tietokantasovellustoimittaja) käyttävät Sun-koneita tuotekehitykseen. Haittaa ei ollut siitäkään, että Sun on ainut laitteistotoimittaja, jolla on oma ja ilmeisen tehokas tukiyksikkö kirjastoille ja kirjastojärjestelmätoimittajille. Endeavor on usein korostanut hyviä yhteistyösuhteitaan Sunin kanssa.

Suurien palvelinten luotettavuus perustuu suurelta osin mekaanisten osien kahdentamiseen. Kahdennus - esimerkiksi levyjen peilaus - on kallista, mutta välttämätöntä, jos halutaan rakentaa todella luotettava palvelin. Pienissä palvelinkoneissa kahdennus on yleensä puutteellista ja rautatason ongelmat siksi tavallisempia kuin isoissa palvelimissa.

Valitettavasti rautaongelmat ovat yleensä seurauksiltaan vakavia: tavallisesti palvelin ei ole käytettävissä kunnes vikaantunut osa on korjattu. Esimerkiksi hajonnut levy on vaihdettava, ja tämän jälkeen levyrikon yhteydessä kadonnut data palautettava viimeisimmältä varmistusnauhalta. Pahimmillaan levyrikko - tavallisin laitetason tekninen ongelma - voi pitää koneen suljettuna kokonaisen päivän ja aiheuttaa myöhemminkin ikäviä ongelmia datan häviämisen tai korruptoitumisen vuoksi.

Uuden Linnea-palvelimen teknisestä laadusta kertoo se, että Sun takaa E10000:n käyttöasteeksi vähintään 99.95 %, mikä tarkoittaa että palvelinta joudutaan vuosittain pitämään ylläpito- tai korjaustöiden vuoksi suljettuna korkeintaan muutaman tunnin. Teknisen laadun lisäksi E10000-palvelimien luotettavuus perustuu sitä varten kehitettyihin erikoisohjelmistoihin, jotka helpottavat koneen managerointia. E10000-käyttäjien joukossa on vakuutusyhtiöitä, pankkeja ja öljy-yhtiöitä. Linnea-kirjastot ovat siis varsin hyvässä seurassa. Muista Voyager-käyttäjistä ainakin Kongressin kirjasto ja Georgian kirjastoverkko ovat hankkineet E10000-palvelimen. Kone on siis Endeavorille jo tuttu.

Suunnittelemattomat käyttökatkot ovat E10000-koneissa erittäin harvinaisia, koska käytännössä kaikki mekaaniset osat on kahdennettu. Esimerkiksi virtalähteitä on meille toimitettavassa E10000-kokoonpanossa kuusi. Niistä kaksi voi olla rikki samanaikaisesti ilman että koneen toiminta häiriintyy millään tavalla. Myös muita hajoamiselle alttiita mekaanisia osia kuten tuulettimia on ripoteltu koneeseen riittämiin. Kaikki huoltotoimet prosessorien lisäämisestä lähtien voidaan tehdä lennosta. Käyttöjärjestelmäpäivityksen kaltaiset operaatiot voidaan E10000-koneiden erillisen hallintatyöaseman ansiosta tehdä nopeasti.

Osta yksi kone, saat neljä ilmaiseksi…

Sun E10000-palvelimen erottaa muista Sunin koneista ja ylipäätään muista tietokoneista se, että se ei oikeastaan ole yksi kone, vaan usean koneen looginen klusteri. Yksi E10000-palvelin voidaan jakaa aina 16 erilliseen osaan eli domainiin. Linnea-verkon E10000 jaetaan aluksi viiteen osaan; myöhemmin niiden määrää voidaan lisätä tarpeen mukaan. Kaikki yhteisluettelot sijoitetaan yhteen domainiin, Helsingin seudun kirjastojen tietokannat toiseen ja kaikkien muiden kirjastojen kannat hajasijoitetaan tasaisesti kolmeen jäljelle jääneeseen domainiin. Yhteisluettelo- ja Helsinki-domainit ovat kooltaan kaksinkertaisia muihin verrattuna; niissä on kahdeksan prosessoria ja muiden kirjastojen domainissa neljä.

Voyager-sovelluksen ja sen käyttäjien näkökulmasta Linnean E10000-palvelin näyttää viiden erillisen koneen klusterilta: jokaiselle viidelle E10000-koneen domainille tulee oma IP-osoite ja Internet-nimi, ja jokaisella niistä on oma verkkoliitäntä, tai itse asiassa kaksi: domainien verkkoliitännät on varmuuden maksimoimiseksi kahdennettu.

E10000-palvelimessamme mikään palvelintason ongelma ei kosketa kaikkia kirjastoja, koska jokainen domain on verkkoliitännästä lähtien fyysisesti erillään muista. Domaineilla on omat prosessorit, keskusmuisti ja levytila sekä tietenkin käyttöjärjestelmäprosessi, joita valvotaan erilliseltä työasemakoneelta. Erikoisoperaatioita kuten ohjelmistopäivityksiä ei tarvitse sopia kaikkien Linnea-kirjastojen kesken; riittää että saman domainin jakavat kirjastot päättävät asioista keskenään. CPU:n ja muistin lisääminen tai uuden levytilan asentaminen on aina domain-kohtaista ja voidaan tehdä "lennosta". Uusien domainien rakentaminen samalle koneelle ei näy laitteen vanhoille käyttäjille millään tavalla.

Domainien itsenäisyydestä ja helposta laajennettavuudesta seuraa merkittäviä etuja. Jos esimerkiksi yhteisjärjestelmän tietokannat päätetään siirtää vapaaseen hakukäyttöön, voidaan tätä koneen osaa laajentaa ostamalla siihen lisää prosessoreita ja keskusmuistia. Muiden domainien kapasiteettitarpeeseen yhteisten tietokantojen käytön kasvulla ei ole mitään vaikutusta. Jos E10000-laitteelle perustetaan uusi domain uusille kirjastolle, nämä kirjastot ovat teknisesti täysin itsenäisiä vanhoista käyttäjistä. Laajennetusta yhteistyöstä koituu kirjastoille etuja alentuneiden laitteiston hankinta-, tuki- ja ylläpitokustannusten ansiosta.

Uuden tietokantapalvelimen tekniikkaa

Linnea2:n E10000-palvelimeen hankitaan aluksi 28 prosessoria ja 24 gigatavua keskusmuistia. Endeavorin mukaan Sunin syksyllä 1999 esittelemä prosessorityyppi - jota Linnean E10000 käyttää - hoitaa 50 aktiivista Voyager-käyttäjää samanaikaisesti. Jokaista aktiivikäyttäjää kohden koneella on kokemuksen mukaan neljä passiivista käyttäjää, ja yksi prosessori selviää siis 200 samanaikaisesta istunnosta. 28 prosessoria riittää siis 1400 aktiivikäyttäjälle eli yli 5000 sisäänkirjoittautuneelle käyttäjälle. Kun Linnea1-verkon aktiivikäyttäjiä oli keväällä 2000 500-700, voidaan laajennusvaran sanoa olevan kohtuullinen. Endeavorilla on tapana mitoittaa palvelimet konservatiivisesti, jotta suorituskykyongelmilta vältyttäisiin silloinkin, kun näyttöluetteloiden käyttö nousee Voyager-sovelluksen käyttöönoton vuoksi ennustettuakin enemmän.

VTLS:ssä palvelin kuormittuu enemmän kuin Voyagerissa. Tämä johtuu ohjelmistoarkkitehtuurista: VTLS perustuu "tyhmiin päätteisiin", mutta Voyager on client-server -ohjelma, jossa osa töistä hoituu client-ohjelmissa. Esimerkiksi luetteloija kuormittaa VTLS:ssä palvelinta aina lähettäessään uuden MARC-kentän palvelimelle return-näppäintä painamalla. Voyagerissa vasta valmis, luettelointisovelluksessa viimeistelty tietue lähtee palvelimelle prosessoitavaksi. Tiedonhaussa VTLS:n HP3000-palvelin rakentaa näytöt (kortti-, MARC- ja niin edelleen), mutta Voyagerissa tästä työstä vastaa käyttäjän client-sovellus ja PC, jolla se toimii. Käytettävissämme ei ole ollut tarkkaa tietoa siitä , miten paljon Voyager-palvelimen kuorma putoaa VTLS:ään verrattuna. Tätä kuorman alennusta ei siksi ole otettu huomioon kapasiteettilaskelmissa.

Kirjastojen tietokantojen suosio on jatkuvasti noussut 20-30 % vuodessa. Siksi yhteistä palvelinta pitää ennen pitkää laajentaa. Sunin pienimmissä palvelimissa kasvun rajat olisivat tulleet nopeasti vastaan, koska työasematason laitteisiin voidaan asentaa vain yksi prosessori. E10000-koneessamme kasvunvaraa on reilusti, sillä siihen voidaan asentaa maksimissaan 64 prosessoria ja 64 gigatavua keskusmuistia. Palvelimen kapasiteetti voidaan siis tältä osin nostaa yli kaksinkertaiseksi. Uutta levytilaa voidaan ostaa periaatteessa rajattomasti.

Entäpä jos käyttäjien määrä nousee niin, että E10000:n laajennusvara ei enää riitä? Helpoin menettely on ohjelmiston jakaminen niin, että tietokannat ja indeksit jäävät nykyiselle koneelle, mutta Voyager-sovellusmoduli (application module) siirretään erilliselle palvelimelle. Pidän kuitenkin lähes varmana, että E10000-koneen käyttöiän aikana koneen laajennusvara ei lopu kesken. Ja kun E10000-kone 5-10 vuoden kuluttua korvataan uudella, on - jos päädymme jälleen keskitettyyn koneeseen - sopivia laitemalleja jo pelkästään Sunilla useita, ja niiden kaikkien kapasiteetti on verkon tarpeisiin nähden yltäkylläinen. Tietokoneiden tehon kasvu on ollut jatkuvasti nopeampaa kuin kirjastojen käytön kasvu, eikä mikään viittaa siihen, että tämä trendi seuraavien viiden vuoden aikana muuttuisi. Päinvastoin: ennakkotiedot Sunin ja IBM:n uusista koneista kertovat laskentakapasiteetin jatkuvasta eksponentiaalisesta kasvusta. Tiedot talteen

Yhteisen palvelimen Voyager-tietokannat sijoitetaan neljään Sun A5200-levyalijärjestelmään. A5200 on luotettava laite, jossa levyille sähköä syöttävät virtalähteet ja tuulettimet on kahdennettu. Jokaiseen A52000-järjestelmään asennettiin 22 kappaletta Sunin loppuvuodesta 1999 esittelemiä nopeita 18.2 gigatavun kuitulevyjä, jotka sopivat hyvin järeään tietokantapalvelimeen. Yhteensä tietokannoille on siis hankittu 1.6 teratavua levytilaa, josta peilattuna saadaan 800 gigatavua käytettävissä olevaa levyä.

Kirjastojen ja Voyagerin antamien tietojen avulla laskimme, että jo 400-500 gigatavua riittäisi hyvin kaikille Linnea-tietokannoille. Suurempi levymäärä on tarpeen I/O-kapasiteetin riittävyyden takaamiseksi. Jos samaa indeksiä lukee satoja käyttäjiä samanaikaisesti, indeksi on hyvä hajauttaa useammalle fyysiselle levylle. Yhtenä vaihtoehtona harkittiin 9.1 GB levyjen käyttöä, mutta Endeavorin mukaan tämä ei ollut tarpeen.

Levyjen peilaus periaatteessa tuplaa datan lukukapasiteetin. Kun tietokannat on kahdennettu, esimerkiksi indeksin luku voidaan tehdä joko alkuperäisestä indeksistä tai sen kopiosta, riippuen siitä kumman levy on joutilaampi. Datan kirjoittamisessa parannusta normaalitilanteeseen ei tapahdu, koska kaikki data on kirjoitettava kahdesti. Onneksi Voyagerissa ja muissa kirjastojärjestelmissä suurin osa I/O-operaatioista on levyltä lukua. E10000-palvelimen keskusmuistin suuri määrä on myös avuksi: kun merkittävä osuus datasta voidaan pitää keskusmuistissa koko ajan, levyI/O:ta tarvitaan vähän ja toiminnot ovat hyvin nopeita.

Palvelimen viidelle Solaris-käyttöjärjestelmäkopiolle - joka domainilla on omansa - hankittiin omat peilatut levyt. Tämä helpottaa koneen ylläpitoa ja lisää Voyagerille tarjolla olevaa kapasiteettia.

E10000-palvelimelle ei hankittu omaa nauhavarmistuslaitetta, vaan tietokannat varmistetaan CSC:n käyttämälle nauharobotille CSC:n käyttämällä UNIX-sovelluksella, joka sallii online-varmistukset.

Uusi ja vanha kone - vertailua

Linnea-verkon E10000-palvelimen teho ja välillisesti myös tietotekniikan huikea kehitysvauhti tulee selväksi, jos vertaamme Linnea-verkon alkuperäistä yhteisjärjestelmäkonetta ja nyt ostettua laitetta toisiinsa. Linnea1:n 1992 ostetussa HP3000 992/100 -koneessa oli yksi, kellotaajuudeltaan 66 MHz:n prosessori, 256 megatavua keskusmuistia sekä noin 17 gigatavua levytilaa. Kone edusti RAID-levyineen oman aikansa huipputekniikkaa, ja palveli meitä vuosia hyvin.

Uuden palvelimen prosessorien kellotaajuus on 400 MHz, eli kuusinkertainen alkuperäiseen yhteisjärjestelmäkoneeseen verrattuna. Lisäksi uudet prosessorit pystyvät suorittamaan rinnakkain useita käskyjä, toisin kuin 90-luvun alun prosessorit. Vaikka prosessoritehon suora vertailu eri valmistajien prosessoreiden välillä on vaikeaa, voidaan perustellusti väittää että uudet Sun-prosessorit ovat vähintään kymmenen kertaa 90-luvun alun HP-prosessoreita nopeampia ja uusi laite vastaa siksi CPU-teholtaan noin 300 kahdeksan vuoden takaista yhteisjärjestelmäkonetta.

CPU-teho on tietenkin vain yksi oleellinen muuttuja; muita ovat esimerkiksi keskusmuistin ja levytilan määrä. Keskusmuistia ja levyä uudessa koneessa on noin sata kertaa enemmän kuin ensimmäisessä HP3000-yhteisjärjestelmäkoneessa. Uuden palvelimen yksittäisen levynkin tallennuskapasiteetti on suurempi kuin koko alkuperäisen yhteisjärjestelmäkoneen.

Tietotekniikan kehityksen toinen puoli on se, että uudet sovellukset vaativat toimiakseen entistä nopeampia koneita. Sunin Solaris-käyttöjärjestelmä, Oracle ja Voyager ovat raskaampia ohjelmia kuin MPE-käyttöjärjestelmä, Image-tietokanta ja VTLS-sovellus. Vaikka Linnea2-verkon uusi palvelin on erittäin nopea, mitään pröystäilyä se ei ole - laitteen kapasiteetti tulee tarpeeseen.

WWW-käyttöliittymäsovelluksen palvelin

Järeän tietokantapalvelimen lisäksi Linnea-kirjastot tarvitsevat palvelimen tai palvelimia myös Voyagerin WWW-käyttöliittymäsovellusta eli Web Voyage -ohjelmaa varten. Jos tietokantoja varten tarvitaan iso palvelin, voidaan WWW-sovelluksen tarvitsemaa kapasiteettia hankkia tyyten toisentyyppisin laittein. Tietokantapalvelimen ja WWW-palvelimen tekniset vaatimukset kun poikkeavat suuresti toisistaan. Myös sijoituspaikka on vapaa - Voyagerin WWW-palvelimet voidaan sijoittaa minne vain, riittää että tietokantapalvelimelle on kohtuullisen nopea TCP/IP-yhteys.

Monilla yliopistoilla on jo valmiiksi pieniä Sun-palvelimia, jotka soveltuvat WWW-edustakoneiksi. Tällöin ei uutta konetta tarvitse ostaa. Kapasiteettivaatimukset eivät ole suuret; tehonsa puolesta pieni työasemakone riittää suurellekin kirjastolle, kunhan sillä ei ajeta muita kuin Web Voyagen edellyttämiä ohjelmistoja.

Yhteisjärjestelmätietokantoja varten hankitaan kuitenkin uusi WWW-palvelin vuoden 2001 keväällä. Erillinen palvelin on tarpeen, koska E10000-koneelle ei haluta päästää lainkaan WWW-käyttäjiä, ei edes erilliseen domainiin. Linnea-verkon E10000 suojataan tietoturvan parantamiseksi palomuurilla, mutta WWW-edustakone on kätevintä pitää palomuurin etupuolella. Koska E10000-koneen kaikkien domainien on tietoturvasyistä oltava palomuurin takana, tarvitaan WWW-käyttöä varten siksi oma kone. Erillisen koneen hankintaa puoltavat myös kustannussyyt.

Sun ja muut laitevalmistajat ovat parin viime vuoden aikana julkaisseet uusia laitemalleja, jotka on tarkoitettu erityisesti WWW-palvelinkäyttöön. Sunin Netra-palvelimet ovat pizzaboksin kokoisia palvelimia, joita voidaan pinota yhteen räkkiin kymmeniä. Suuret Sun-pohjaiset WWW-palvelinjärjestelmät rakennetaan tätä nykyä Netra-palvelimista, jotka klusteroidaan erillisen hallintaohjelman avulla.

Yhteisluetteloiden WWW-hakupalvelu voidaan rakentaa Netra-koneiden varaan siten, että jokaisen tietokannan Web Voyage-ohjelma asennetaan klusterin jokaiseen Netra-palvelimeen. Hallintaohjelma ohjaa uudet käyttäjät siihen Netraan, joka on vähiten kuormitettu. Jos koko Netra-palvelinklusteri kuormittuu liiaksi, ongelma poistuu helposti lisäämällä klusteriin uusi Netra. Laajennusvaraa on meidän tarpeisiimme "riittävästi". Klusteri on myös turvallinen: jos jokin palvelin kaatuu, muut astuvat sen tilalle.

Endeavorin mukaan Netra-palvelinperheen pienin kone (Netra t1) voi hoitaa noin 100-150 aktiivista Web Voyage -käyttäjää. Teholtaan tämä laite vastaa Sunin muita pieniä työasemakoneita. Koko Linnea-verkon osalta Web Voyagen kapasiteettitarpeet voidaan siis tyydyttää arviolta 3-4 Netra-palvelimella tai vastaavalla koneella. Ammattikäyttäjät menevät tietokantapalvelimelle suoraan omien client-ohjelmiensa avulla, joten kapasiteettilaskelmassa tarvitsee ottaa huomioon vain tiedonhakuja tekevät asiakkaat. Heistäkin osa tulee käyttämään Suomeen ostettua OCLC:n WebZ-käyttöliittymäsovellusta, joka kommunikoi palomuurin läpi suoraan Voyagerin Z39.50-palvelimen kanssa.

Yhden Netra t1-palvelimen hinta on elokuussa 2000 noin 40.000-50.000 markkaa, joten laitteistokustannukset eivät tässä vaihtoehdossa nouse kovin korkeiksi - ensi vuoden kevääseen mennessä hinnat pudonnevat vielä jonkin verran. Netra-klusterin hankintaohjelma maksaa 3 koneelle noin 100.000 markkaa, ja jokainen uusi Netra-purkki nostaa lisenssin hintaa noin 15.000 markkaa.

Netra-klusterin asemesta voisimme Kongressin kirjaston tapaan hankkia pienen Sun-palvelimen WWW-edustakoneeksi. Esimerkiksi E450-palvelimeen saataisiin 4 prosessoria. Mutta tässä ratkaisussa laajennusvaraa ei olisi lainkaan, ja palvelimen käyttövarmuus olisi heikompi kuin Netra-klusterissa. Siksi todennäköisin yhteisjärjestelmän WWW-edustakoneen toteutusvaihtoehto on Netra t1-klusteri.

Yhteisluetteloille hankittavaa Netra-klusteria voivat tietenkin halutessaan hyödyntää muutkin kirjastot. Jos esimerkiksi Helsingin seudun kirjastot päättävät hankkia pari Netra-palvelinta, ne voidaan lisätä klusteriin jo siellä olevien palvelimien jatkoksi. Hallintaohjelmalla voidaan määritellä, että uudet Netrat palvelevat vain Helkaan ja muihin helsinkiläisiin näyttöluetteloihin meneviä käyttäjiä.

FUNETin ominaisuuksista

Pelkällä palvelimella me emme tietenkään pitkälle pötki, vaikka se olisi miten hyvä. Verkkoyhteyksien kirjastoista yhteiselle palvelimelle ja WWW-edustakoneille on pakko toimia moitteettomasti.

Uuden palvelimen sijainti FUNET-verkon keskuksessa CSC - Tieteellinen laskenta Oy:ssä on Linnea2:n kannalta mahdollisimman edullinen. Vasteajat yliopistoista verkon keskukseen Otaniemeen ovat verkon reunoiltakin Voyagerille taatusti riittävän nopeat. Toisin kuin VTLS, Voyager on rakennettu niin, että se ei edellytä nopeita verkkoyhteyksiä. VTLS-ohjelmistossahan tietueiden kopiointi perustuu HP:n omaan protokollaan, jossa dataa siirretään 80 tavun paloina ja joka palasen jälkeen pyydetään kuittaus. Yhden MARC-tietueen siirtäminen voi siis edellyttää monia edestakaisia "matkoja" ja saapuneen datan kuittauksia. Voyagerin toiminta on tässä suhteessa paljon suoraviivaisempaa; data siirtyy suuremmissa paloissa ilman kuittauksia, joita ei itse asiassa tarvita, koska Internet-verkossa käytettävä TCP/IP-protokolla takaa tiedon luotettavan siirtymisen. Esimerkiksi amerikkalainen Keystone network toimii hienosti paljon FUNETia heikompien yhteyksien varassa, vaikka yliopistot eivät ole kovin paljon omiamme pienempiä.

CSC:n asemesta palvelin olisi FUNETin tehokkuuden vuoksi voitu sijoittaa periaatteessa mihin tahansa yliopistokaupunkiin, koska kaikki FUNET-yhteydet on kahdennettu ja kaikkien linjojen kapasiteetti on sama. Sijoituspäätöksen ratkaisi CSC:n palvelun taso. Jo CSC:n konesali on turvallisuudeltaan erinomainen. Koska samassa salissa ovat Suomen kansalliset superkoneet, tila on rakennettu viimeisen päälle. Varmuuden vuoksi kirjastojen yhteiselle palvelimelle hankitaan kuitenkin palovakuutus.

CSC:n Solaris- ja Oracle-asiantuntemus on erittäin hyvä. CSC:n eduksi laskettiin sekin, että vuonna 2001 avautuu mahdollisuus laitteiden ympärivuorokautiseen päivystykseen, mitä yliopistot eivät käytännössä pysty tarjoamaan nyt eikä tulevaisuudessa.

FUNETin runkoverkon kapasiteetti oli kesällä 2000 2 x 155 Mbps. Yhteydet on rakennettu pääosin Elisa Oyj:ltä vuokratuilla ATM-yhteyksillä (katso http://www.csc.fi/suomi/funet/verkko.html).

FUNET-yhteyksien katkeaminen kriittisessä kohdassa haittaisi kaikkia Linnea-kirjastoja niin nyt kuin jatkossakin. Tällaisen katastrofin todennäköisyys on hyvin pieni koska kaikki FUNET-yhteydet on kahdennettu. Verkon sydämeen eli CSC:n toimitaloon tulee peräti kolme kaapelia eri suunnista. Vielä 90-luvun alussa FUNET oli tähtiverkko yksinkertaisin yhteyksin ja hitain varayhteyksin, minkä koki konkreettisesti silloin kun linja meni poikki.

FUNETin tukkeutuminen liikenteen nopean kasvun vuoksi on epätodennäköistä. Tekniikka on kehittynyt samassa tahdissa liikennemäärien kanssa, ja verkon vasteajat ovat 90-luvun mittaan lyhentyneet verkkoliikenteen kasvusta huolimatta. FUNET-verkon suuren merkityksen vuoksi lienee käytännössä varmaa, ettei verkon tasoa jatkossakaan päästetä heikkenemään. Se olisi liian paha isku esimerkiksi maamme maineelle tietotekniikan huippumaana. Nopeasti kehittyvä tekniikka antaa hyvät edellytykset pysytellä käytön kasvun edellä. Seuraava suuri FUNET-päivitys, jolla kapasiteetti nostetaan 622 Mbps:ään on jo suunnitteilla, ja operaatio toteutetaan vuonna 2001.

FUNETin runkoverkon luotettavuus on omien kokemuksieni mukaan koko 90-luvun ajan parantunut. Silloin kun Linnea-yhteistyö alkoi, FUNET-verkossa oli ongelmia silloin tällöin, ja etenkin silloin kun ATM-tekniikka oli uutta ja FUNET siirtyi siihen ensimmäisten joukossa. Nyt ongelmat ovat niin harvinaisia, että en muista koska FUNETin runkoverkossa on viimeksi ollut meille asti näkyneitä ongelmia. Mikään ei viittaa siihen että tämä positiivinen kehitys kääntyisi huonompaan suuntaan.

Vaikka FUNET on toiminut hyvin, nykyisen yhteisjärjestelmäkoneen käyttö ei ole aina sujunut juoheasti, koska tietoliikenneyhteydet yliopistojen omissa verkoissa ovat pätkineet. Yliopistojen paikallisverkoissa on ollut ongelmia muun muassa liikennemäärien ja laitteiden määrän nopean kasvun vuoksi. Esimerkiksi Helsingin yliopiston jättimäisessä verkossa tuotteet, jotka ovat toimineet moitteettomasti pienemmissä verkoissa, ovat toisinaan reistailleet. Syntyvät ongelmat ovat toisinaan olleet hyvin vaikeita ratkoa, siitä huolimatta että yliopiston verkkojaoksen työntekijöiden ammattitaito on erinomainen.

Voyagerin ominaisuuksista

Tietoliikenneverkko ja palvelinkone eivät ole ainoat seikat jotka vaikuttavat kirjastojärjestelmän käytettävyyteen. Myös ohjelmistolla on oma roolinsa tässä kokonaisuudessa.

VTLS:ssä on pakko panna lappu luukulle, jos palvelin tai verkkoyhteys sille eivät toimi. Tyhmä pääte on kirjaimellisesti tyhmä silloin, kun VTLS-sovellus ei kerro sille mitä tehdä. Voyagerissa moni asia toimii ainakin lyhyitä aikoja client-sovellusten omin avuin, vaikka palvelin ei olisi tavoitettavissa. Pienien käyttökatkojen haitta esimerkiksi lainaukselle jää siten pieneksi.

Voyagerin toiminta perustuu konsortiotoimintojen (Universal catalog & borrowing) osalta siihen, että kaikki tietokannat ovat nopeasti tavoitettavissa. Z39.50-pohjainen virtuaalinen yhteisluettelo on myös nopeita verkkoyhteyksiä edellyttävä palvelu. Keskitetty palvelinkone tarjoaa Z39.50-pohjaisille virtuaalisille yhteisluetteloille sekä Voyagerin muille monien näyttöluetteloiden käyttöön perustuville lisäominaisuuksille parhaan alustan, koska kaikki virtuaalisen yhteisluettelon palaset ovat samalla palvelimella ja siten nopeasti tavoitettavissa.

Voyager ja uusi palvelin mahdollistavat tietokantojen pitämisen auki 24 tuntia vuorokaudessa. E10000-koneelle on hankittu on-line -varmistuksien ottamisen mahdollistava sovellus. Voyager-manageroinnissa ei tarvita päivittäin ajettavia erätöitä, joiden ajaksi käyttäjät on hätistettävä pois. Jos tietokannat voidaan sovelluksen puolesta pitää aina käytettävissä, on myös palvelinkoneen sallittava jatkuva aukiolo. Tässä suhteessa E10000 ei todellakaan aseta mitään rajoituksia.

Onko Voyager ylipäätään luotettavampi ohjelmisto kuin VTLS? Tähän kysymykseen ei ole yksiselitteistä vastausta. Luotettavuuteen vaikuttavat varsinaisen kirjastojärjestelmän lisäksi tietokantasovellus ja käyttöjärjestelmä, ja tiedämme omasta kokemuksesta että HP3000:n MPE-käyttöjärjestelmä sekä TurboIMAGE-tietokantasovellus ovat erittäin vakaita. Voyager-käyttäjiltä saamiemme tietojen mukaan yhdistelmä Solaris, Oracle ja Voyager on kuitenkin hyvin luotettava.

Lopuksi

Palveluiden ja palvelinkoneiden keskittämisestä on viimeisen 10 vuoden aikana tullut yleinen trendi yrityksissä, jotka ovat ylipäätään yliopistoja kustannustietoisempia. Tosin yliopistoissakin suunta on muuttumassa. Koneiden hankintahinnan ohella arvioidaan myös ylläpitokustannuksia. UNIX-osaajat eivät enää ole yliopistoissakaan rajaton luonnonvara.

Vielä 90-luvun alussa atk-resurssit hankittiin yleensä omaan yliopistoon. Verkkoyhteydet eivät tuolloin olleet järin nopeita eivätkä luotettavia. 2000-luvun alussa luottamus verkkoon ja myös riippuvuus verkkoyhteyksistä ja tietotekniikasta yleensä on suuri. Kirjastot eivät muodosta tässä suhteessa poikkeusta, pikemminkin päinvastoin. Palvelumme perustuvat tietotekniikan soveltamiseen. Kasvava osa kokoelmistakin on FinELib-hankkeen ja monien pienempien projektien ansiosta verkkoyhteyden takana, ja usein vielä ulkomailla. Tästä ei ainakaan minun tietääkseni ole kannettu mitään erityisempää huolta, ja teknisesti järjestely on toiminut hyvin. Haitat ovat ilmeisesti olleet pienet, vaikka ulkomaan yhteyksillä on vääjäämättä enemmän ongelmia kuin kotimaassa.

USA:ssa on useita Linneaa vastaavia tai sitä isompia verkkoja jotka on rakennettu Linnea2:sta vastaavan tai sitä heikomman teknologian varaan. Silti sielläkin verkko- ja palvelinongelmat ovat olleet hyvin harvinaisia. Olen varma että meillä tilanne tulee olemaan sama, kun Voyager ja E10000-palvelin pääsevät tositoimiin vuoden 2001 kesällä ohjelmiston sopeutuksen ja tietokantojen konvertoinnin jälkeen.

Linnea2:ssa tehdyt ratkaisut ovat esimerkki siitä, miten tietotekniikan soveltaminen muuttaa kirjastojen mahdollisuuksia. Yhteinen palvelin vähentää oleellisesti UNIX-ylläpitoon tarvittavaa aikaa. Laitteiston laajentaminen ei sekään enää ole yhden kirjaston sisäinen asia, vaan voidaan hoitaa yhteistyössä ja käyttäen parasta saatavilla olevaa asiantuntemusta.

Juha Hakala, kehittämisjohtaja
Helsingi yliopisto kirjasto
Sähköposti: Juha.Hakala AT helsinki.fi

Tietolinja 1/2000