Author: Janne Peltonen

Kohtapuoliin alkaa katko. Maanantaihin mennessä systeemit ovat sitten toiminnassa taas.

Kirjoitin eilen sen, mikä oli kriittistä. Tänään voisi kirjoitella vähän muitakin kuulumisia.

Järjestelmä oli siis pystyssä jokseenkin aikataulun mukaisesti kesäkuun alussa, ja sen jälkeen on tehty postien kopiointeja vanhasta järjestelmästä uuteen. Yhteen isoon siirtoajoon kului kolmisen vuorokautta, ja päivityajoihin näyttäisi aina kuluvan noin vuorokausi. Ensimmäiset siirrot tehtiin siten, että replikajärjestelmä Kumpulassa ei vielä ollut pystyssä. Sitten sekin nostettiin pystyyn, kaikki käyttäjät ja bulletin boardit synkronoitiin (tähän meni pari vuorokautta), ja loput synkronointiajot on tehty replikoitavaan järjestelmään.

Ongelmiakin on tullut vastaan, nimittäin sellaisia, jotka saattoikin havaita vasta täysikokoisesta järjestelmästä. Ehkä eniten harmia aiheutti sellainen pieni suunnitteluvirhe sähköpostiohjelmistossa, josta seurasi, että aina yhtä Cyrus-parven jäsentä pystytettäessä se ensin poisti sähköpostikansiolistastaan tiedot kaikilla parven muilla jäsenillä sijainneista postikansioista – ja sitten kopioi ne takaisin. Tämä kuitenkin saatiin korjatuksi, ja järjestelmän uudelleenkäynnistykseen menevä aika on taas järkevä. Nämä synkronointiajot ovat kyllä olleet varsin mainiota kuormitustestausta.

Kaiken kaikkiaan järjestelmä toimii hyvin ja nopeasti. Maanantaina tehdyn järjestelmällisen testauksen yhteydessä tuli varmistetuksi, että normaalit toiminnot onnistuvat kaikilla tuetuilla Windows-asiakasohjelmistoilla. Jo aiemmin oli varmistuttu, että järjestelmä toimii myös ainakin Pinen, Muttin, GNUsin ja Linux-Thunderbirdin kanssa. Niin, ja Webmail-asiakasohjelmisto IMPin.

Siirtymä lähestyy, ja siitä on tiedotettu vähän joka paikassa – viimeksi Webmailin etusivulla ja käyttäjien postilaatikoissa. Kaikenlaisia villejä huhuja on kierrellyt, mitä voinee pitää oppituntina tiedottamisessa. Todettakoon tässäkin siis vielä: postit eivät ole katoamassa minnekään. Katkon aikana saapuvat postit toimitetaan perille, ja ne ovat luettavissa maanantaina katkon jälkeen.

Toinen asia, joka on herättänyt ihmetystä, on katkon pituus. Tämän voi selittää lyhyesti tai pidemmästi.

Lyhyt selitys: Posteja on paljon, ja niiden viimeiseen synkronointiin vanhan mappi-systeemin kanssa menee aikaa.

Pitkä selitys: Posteja on vanhassa postijärjestelmässä noin 1,7 teratavua noin 50 000 käyttäjällä ja noin 400 yhteispostilaatikossa noin 500 000 postikansiossa. Posteja on siis paljon. Jotta kaikki posteihin liittyvä metadata – tieto siitä, mitkä viestit ovat uusia ja mitkä eivät, mitkä luettuja ja mitkä eivät, mihin on vastattu ja mihin ei, mitkä on merkitty tärkeiksi ja mitkä ei, mitkä on merkitty poistettaviksi ja mitkä ei – tulisi siirretyksi, siirto on tehtävä oikeastaan vain postien lukemiseen tarkoitetulla IMAP-protokollalla. Siirto on siis varsin hidasta verrattuna siihen, että raakadataa vain kaataisi verkon läpi. Vaikka postien suuri massa on toki siirretty jo etukäteen ja voidaan siirtää elävästä järjestelmästä uuteen, yksi synkronointi on kuitenkin tehtävä alas ajetusta järjestelmästä uuteen, jotta voidaan olla varmoja, että posteja ei jää siirtämättä. Siksi on tehtävä yksi siirto katkon aikana. Suurin osa katkon ajasta siis kuluu siihen, että järjestelmä varmistaa vanhojen postikansioiden sisältöjen olevan vastaavia uusien kanssa.

Uuteen Mappi-järjestelmään siirrytään heinäkuun puolessavälissä, 13.-15. heinäkuuta. Tänä aikana Mappi-postit ovat poissa käytöstä.

Pyrimme siihen, että useimpien käyttäjien ei tarvitsisi muutoksen jälkeen tehdä muutoksia sähköpostiohjelmansa asetuksiin; oikeastaan ainoa mahdollisesti asetusmuutoksia vaativa asia on se, että suojaamattomat IMAP-yhteydet lakkaavat toimimasta myös Unix-palvelimilta ja sisäänsoittolinjoilta.

Kuukausi on mennyt ilman päivityksiä. Lupasin kyllä päivittää tätä säännöllisesti—mutta jos tapahtuu paljon, ei ehdi päivittää; jos ei tapahdu mitään, ei ole päivitettävää.

Tietotekniikkaa yliopistolle -lehti ilmestyi, ja siinä oli juttu Mappi-uudistuksesta. Yksi korjaus ja yksi täydennys:

• Tieto siitä, mitkä viestit ovat uusia ja mitkä nähtyjä, säilyy siirtymän yli.
• Suojaamattomat IMAP-yhteydet lakkaavat toimimasta mistään—tähän astihan ne olivat toimineet yliopiston Unix-palvelimilta ja sisäänsoittolinjoilta.

Laitteistot

Huhtikuun aikana saatiin laitteet tilatuksi ja Kumpulan osalta jopa suurimmaksi osaksi räkkeihin ruuvatuiksi. Vallilaan tuli neljä HP:n Bladea ja (hiukan jälkijunassa) sitten kuitenkin HP:ltä yksi 1U:n räkkipalvelin Mupdate Masteriksi. Lisäksi Vallilan konesali-infrastruktuuria parannellaan: saadaan uusi Blade-kehikko, johon asennetaan puolet Bladeista, ja lisäksi saadaan uusi räkki, johon asennetaan uusi Blade-kehikko. Uuden räkin toimitus on hiukan viivästyttänyt asennuksia. Vanhan Blade-räkin kanssa on myös ollut pientä viilausta.

Ilmeisesti uusi räkki kuitenkin saadaan paikoilleen jo ensi viikolla, ja verkko-, kuitu-, sähkö- ja kehikkoinfrastruktuurin pitäisi olla paikallaan siihen mennessä, kun projektin päävastuuhenkilö (siis minä) palaa lomalta 23.5. Uusi levyjärjestelmäkin saataneen asennetuksi kesäkuun toisen viikon aikana, joten silloin pitäisi jo saada 6 teratavua kuitulevyä käyttöön. Huimia lukuja. Parin vuoden jälkeen mennään jo varmaan eksatavuissa.

Siirtymän suunnittelu

Laitteistotoimituksia odotellessa on ollut hyvin aikaa pohtia siirtymän yksityiskohtia: kuinka saadaan mahdollisimman huomaamattomasti (käyttäjien kannalta) siirrettyä liki 50 000 käyttäjää aivan uudenlaiseen IMAP-järjestelmään. Tässä olennaisia yksityiskohtia siirtosuunnitelmasta tekniikasta kiinnostuneille:

• käyttäjät siirretään IMAP-protokollalla, jolloin kaikki viesteihin liittyvä metadata (viesti nähty, viestiin vastattu, viesti tärkeä…) saadaan talteen
• yhteispostilaatikot siirretään kuitenkin tiedostosiirtona rsyncillä, koska ei ole selvää, kenä käyttäjänäkään ne pitäisi siirtää
• myös quotatiedot ja sieve-skriptit lienee yksinkertaisinta siirtää rsyncillä
• sieve-skriptit pitää myös konvertoida uuteen muotoon—kahdella eri muuntotyökalulla, koska Cyruksen versiomuutos on niin iso
• data siirretään vanhasta järjestelmästä uuteen tausta-ajona vanhan järjestelmän ollessa käytössä—ensimmäiseen siirtymään menee noin viikko ja se aloitetaan heti, kun uusi järjestelmä on pystyssä
• massasiirtymän jälkeen datat synkronoidaan kerran vuorokaudessa
• siirtymäkatkon kytketään postin vastaanotto Mappiin pois ja tehdään vielä viimeinen synkronointi
• käännetään posti tulemaan uuteen järjestelmään
• nostetaan vanhat tiedekunta-mappi-osoitteet pystyyn uudessa järjestelmässä
• ja lopulta avataan liikenne ulkomaailmaan.

Viime viikolla saatiin varsin hyvin aikaan se, mitä pitikin: palvelimet tilatuiksi ja testi-Mappi-palvelut klusteroiduiksi.

Klusterointi

Jokainen testi-Mappi-palvelu on nyt RedHat-klusteroitu palvelu. Kuhunkin palveluun kuuluu neljä resurssia:

• ip-osoite
• metadatatiedostojärjestelmä
• postintalletustiedostojärjestelmä ja
• käynnistys-sammutus-status-skripti.

Kun palvelu nostetaan pystyyn tietyllä klusterin solmulla, liitetään solmun verkkoliitäntään haluttu ip-osoite, pystytetään tiedostojärjestelmät ja ajetaan käynnistysskripti. Kun palvelu sammutetaan tietyltä solmulta, tehdään vastaavat toimenpiteet toisin päin. Edellisviikkoisen virtualisoinnin ansiosta eri palvelut voidaan nostaa pystyyn millä tahansa solmulla tai vaikka kaikki palvelut samalla solmulla ilman, että ne häiritsevät toisiaan.

Tässä tietysti vaaditaan, että kullakin klusterisolmulla on käytettävissä tiettyjä resursseja, nimittäin

• verkkoliitäntä, jolla on jo yksi osoite oikeassa verkossa
• pääsy metadatalevylaitteeseen
• hakemisto, johon metadatatiedostojärjestelmä liitetään
• pääsy postinsäilytyslevylaitteeseen
• hakemisto, johon postinsäilytystiedostojärjestelmä liitetään
• käynnistys-sammutus-status-skripti

Laitteisto

Päädyimme lopulta seuraavaan palvelinkokoonpanoon:

Ensisijainen klusteri (Vallilassa)

• 1 kpl Dell 1U-palvelin Mupdate Masteriksi
• 4 kpl HP Blade -palvelimia klusterisolmuiksi

Bladeista kaksi on tarkoitus sijoittaa olemassaolevaan Blade-kehikkoon ja kaksi uuteen, kesään mennessä normaalibudjetista hankittavaan Blade-kehikkoon. Sähkönsyöttö ei ikävä kyllä ole tällä ratkaisulla redundanttia, mutta ainakaan koko klusteri ei mene alas, jos toista kehikkoa on huollettava.

Mupdate Master on erillinen palvelin, koska sen on pakko olla; lisäksi tämä ratkaisee klusterissa sen ongelman, mitä tehtäisiin, jos toisen Blade-kehikon kaaduttua jäisi jäljelle tasan puolet klusterisolmuista (jäljelle jääväkin puolikas ajaisi itsensa alas, koska sillä olisi vain tasan puolet solmuista, eikä se niin ollen voisi olla varma, ettei toinenkin puolikas ole ylhäällä ja yrittäisi myös käyttää klusterin hallinnoimia resursseja). Nyt klusterisolmuista ei koskaan jää jäljelle tasan puolta, koska solmuja on pariton määrä.

Toissijainen eli replikoiva klusteri (Kumpulassa)

• 1 kpl Dell 1U-palvelin Mupdate Masteriksi
• 4 kpl Dell 1U-palvelimia kuituliitännöin klusterisolmuiksi

Kumpulaan ei hankita Bladeja eikä kehikoita, koska näille ei olisi järkevästi tilaa konesalissa.

Palvelimien lisäksi kumpaankin klusteriin pystytetään solmujen välille olemassaolevista osista kahdennettu verkko, jonka kautta klusterin valvonta- ja hallinnointiliikenne kulkee. Verkko kahdennetaan, koska jos se hajoaisi, koko klusteri ajaisi itsensä alas. Kahdentaminen toteutetaan käytännössä Linuxin Channel Bonding -ominaisuuden avulla, jolla siis kaksi verkkoliitäntää saadaan näyttämään yhdeltä.

Lisäksi solmujen välille tarvitaan oma verkko fencingiä varten. Tässä on kyse siitä, että klusterin kadotettua muut yhteydet esimerkiksi jumittuneeseen solmuun se saadaan ajetuksi alas hallitusti (tai sitten väkisin, mutta alas joka tapauksessa). Solmulla olleet palvelut kun uskalletaan nostaa pystyyn jonnekin muualle vasta sitten, kun voidaan olla varmoja, ettei kadonnut solmu enää yritä itse koskea näiden palveluiden vaatimiin resursseihin.

Olen tällä ja viime viikolla keskustellut kovasti Mappi2-työkokonaisuuden tiedotuksesta. Tietotekniikkaosaston tiedotuslehteen on tulossa juttu Mappi-uudistuksesta, ja tämän blogin asema tiedotusvälineenä on ollut keskustelujen kohteena. Koska tätä nyt kuitenkin ilmeisesti saa käyttää, päätin alkaa vastedes kirjoittaa tänne säännöllisesti viime aikojen tapahtumista.

Mitä viime aikoina siis on tapahtunut?

Lisäsin tähän blogiin muutaman kiinteän sivun työkokonaisuutta taustoittamaan: Historia; Tavoitteet ja rajaukset; Tekniikka ja ohjelmistot. Nämä on muokattu varsinaisesta uudistustyökokonaisuussuunnitelmasta hieman luettavampaan ja hieman vähemmän kapulakieliseen muotoon. Katsokaa sinne (pitäisi myös opetella käyttämään tätä blogiohjelmistoa kunnolla: miten tehdään suhteellisia linkkejä noille sivuille?).

Olen myös testaillut Cyrus-IMAPD-palvelun virtualisointia: suostuuko useampi, toisistaan periaatteessa kokonaan riippumaton Cyrus-palvelu toimimaan samalla fyysisellä koneella? Tämä on näet ehdoton edellytys sille, että postipalvelu on klusteroitavissa; idea on se, että kullakin klusterisolmulla ajetaan yhtaikaisesti useaa Cyrus-palvelua, jotka sitten siirretään tasaisesti klusterin muille solmuille, kun yksi solmu ajetaan alas huoltoa varten. Näin mikään kone ei seiso tyhjän panttina – eikä toisaalta millekään koneelle tule mahdotonta kuormaa, kuten kävisi, jos yksi kone (klusterisolmu) joutuisi yhtäkkia palvelemaan kahden koneen kaikkia käyttäjiä.

Lopputulos: toimii. Minulla on tällä hetkellä yhdellä testiympäristöni kolmesta koneesta pyörimässä neljä Cyrus-imap-palvelua, joista kullakin on oma erillinen konfiguraationsa, omat viestitaltionsa, omat ip-osoitteensa – ja jotka toimivat yhdessä Cyrus-parvessa! (Cyrus-parvi on oma suomennokseni Cyrus Murderille, kts. Tekniikka ja ohjelmistot.) Suunnitelma on siis mitä ilmeisimmin toteuttamiskelpoinen. Seuraavaksi pitää saada nämä Cyrus-palvelut vielä klusteroiduiksi; suurin haaste tässä on käynnistys-sammutus-statuksenseuraus-skriptin muokkaaminen klusterointiohjelmistolle sopivaksi. Sitä siis ensi viikon ohjelmassa.

(Pitäisi muuten kirjoittaa testiympäristön kuvaus.)

Kolmas viime aikoina edennyt asia on fyysisten laitteiden tarkkojen ominaisuuksien määrittely. Tällä erää näyttäisi siltä, että olemme hankkimassa kahta Blade-palvelinta ja kahta standalone-palvelinta Vallilaan sekä viittä standalone-palvelinta Kumpulaan. Harkitaan tilauksen tekemistä kuitenkin vielä ensi viikkoon asti.

Tämä sivu on Mappi 2 -uudistuksen tiedotusta varten. Tiedotussivu päätettiin toteuttaa blogina: muokkaaminen on yksinkertaista ja toisaalta ihmiset ovat tottuneet lukemaan blogeja.