Normaalia toimintaa ja käsitesekaannuksia

Mappi selviytyi hyvin opiskelijoiden saapumisesta, ja ruksuttaa kiltisti eteenpäin. Webmailin kanssa on ollut pientä säätöä, ja koska ihmisille ei näytä olevan selvää, että Mappi ei ole Webmail ei ole Mappi (eikä sekään ole selvää, että yliopiston sähköposti ei ole pelkkä Alman osa), voisin linkittää tähänkin muuan hienon kuvan, josta käy ilmi, mikä Mapin ja Webmailin suhde oikeastaan on:

Mappi ja Webmail

Tästä kuvasta näkee, että Mappi on taustalla oleva sähköpostintalletusjärjestelmä, ja Webmail on sähköpostiasiakasohjelma. Siis rinnastettavissa yliopistolla käytössa oleviin Thunderbirdeihin, Outlookeihin tai Mutteihin. Tai Pineihin, Elmeihin, Pegasuksiin, mitä näitä nyt on. Ja jos Webmail on rikki, Mappia voi lukea jollakin muulla. Ja jos postien lukeminen Alman kautta ei onnistu, posteja voi lukea jollakin muulla. (Koska “Alman sähköposti” on oikeasti vain linkki Webmailiin.)

Muuten voisin esittää täälläkin sen mielipiteen, että Webmailia (tai Almaa) ei pidä käyttää ensisijaisena sähköpostinlukutapana. Se on kömpelö ja hidas ja siitä puuttuu monia ominaisuuksia, mitä oikeissa sähköpostiohjelmissa on.

Jälkitestausta ja lastentautien selvittelyä

Systeemi on nyt ollut käytössä kuukauden verran. Kaikenlaista pientä säätöä on ollut:

  • osalla käyttäjistä oli tyhjiä duplikaatteja viesteistään; ne poistettiin
  • ihan muutaman käyttäjän viestit eivät olleet lopulta siirtyneet; ne siirrettiin
  • viestien kopiointi paikallisen ja ei-paikallisen mappi-palvelun välillä ei toiminut; nyt kukaan ei ota suoraan yhteyttä kansioita sisältäviin mappi-palveluihin
  • @hyad-päätteiset tunnukset aiheuttivat hankaluuksia; niillä kirjautuminen estettiin kokonaan (virallisesti tuettu niitä ei ole koskaan)
  • välillä systeemissä esiintyi järkyttäviä kuormituspiikkejä, jotka onnistuivat jumittamaan sen kerran työaikana; syyksi selvisi keskusmuistin vähyys; muistia lisättiin
  • muistiongelmien vuoksi myös varmuuskopiointeihin kului kauan aikaa – sunnuntaina aloitettu täysvarmuuskopio venyi maanantain puolelle; varmuuskopioiden uudelleenjärjestely ja muistin lisäys poistivat ongelma
  • klusterisofta aiheutti huomattavan korkean määrän tiedostojärjestelmäntarkistusskriptin käynnistyksiä, mikä saattoi pahentaa koneen jumittumista muistiongelmien aikana; päätettiin luottaa siihen, että tiedostojärjestelmän ongelmat huomattaisiin palvelun muusta toimimattomuudesta ja poistettiin tarkistus
  • websieven käyttöoikeuslistoissa oli ongelmana se, että oikeuksien poistoyrityksestä seurasikin e-oikeuden antaminen; tämä korjattiin
  • levyjärjestelmällä oli kuormitusongelma, kun samassa levyryhmässä oli yhden mappilevyn lisäksi käsittämättömän määrän kuormaa aiheuttava logipalvelimen levy; logipalvelimen levy siirrettiin muualle
  • edelleen järjestelmän niillä koneilla, joissa klusteripalveluidenhallintaohjelma on käynnissä, esiintyy yhdentoista tunnin jaksolla tonttulakinnäköisiä piikkejä kuormituskäyrässä. Missään muussa järjestelmän kuormittuneisuutta kuvaavassa suureessa (levynkäyttöaste, prosessorinkäyttöaste, verkonkäyttöaste, prosessien määrä) ei esiinny vastaavaa vaihtelua, eikä järjestelmän silmämääräinen vaste ole piikkien aikana sen huonompi kuin muulloinkaan, joten ne eivät varsinaisesti vaikuta järjestelmän käytettävyyteen. Ilmeisesti käyttöjärjestelmäytimen sisällä esiintyy pientä lyhytaikaista odotusta jollakin resurssilla. Asiaa yritetään selvittää edelleen, muttei kovin korkealla prioriteetilla, koska näennäiset kuormituspiikit ovat oikeasti vain Load average -suureen piikkejä, jotka eivät siis havaitusti merkitse sitä, että järjestelmä olisi oikeasti kuormittunut.

Muuten asiat ovat toimineet kuin unelma:

  • systeemi on järkyttävän paljon nopempi kuin edellinen
  • käyttäjien peruspostilaatikon koko saatiin tuplattua, eikä ahtauden merkkejä ole ainakaan vielä näkyvissä
  • yhteispostilaatikoiden käyttäminen mistä vain onnistuu; siirtoja ei tarvitse enää tehdä
  • yhtään vahingossa poistettua yhteispostilaatikkoa ei ole uuden järjestelmän aikana tullut, kun kansionpoisto-oikeus poistettiin kaikilta paitsi yhteispostilaatikoiden ylläpitäjiltä
  • hieno IMAP PUSH -toimintokin toimii (kokeile vaikka kännykälläsi tai Outlookilla!)
  • poistettujen viestien palautus onnistuu muutamassa sekunnissa, ja ne voi vieläpä palauttaa valikoidusti tunnistetietojen perusteella – ei enää hidasta ja epätarkkaa nauhoilta kaivelua
  • replikointikin toimii: kaikki data on olemassa kahteen kertaan, jos meiltä vaikka hajoaisi kokonainen levyjärjestelmä ;)
  • käyttäjät voivat tavoittaa Mapin yhden yhtenäisen osoitteen kautta (posti.mappi.helsinki.fi). Osoitteella on vieläpä Soneran allekirjoittama sertifikaatti, jota useimmat sähköpostiasiakasohjelmat tukevat ilman erillisten juurisertifikaattien asennusta – vielä kun tieto tästä tavoittaisi käyttäjätkin
  • klusterointi tekee rautatason ylläpidosta kevyttä ja mukavaa: toissa tiistaina tehty muistien päivitys pystyttiin tekemään yhteen koneeseen kerrallaan ilman, että käyttäjät huomasivat kuin enintään kaksi kappaletta noin minuutin katkoja palvelussa
  • varmuuskopioiden palautus (jota on jouduttu tekemään tähän mennessä kerran, kun piti palauttaa kokonainen poistettu kansio) mille tahansa fyysiselle klusterikoneelle toimii kauniisti
  • starttls toimii, joten nyt meillä on tuki niillekin mobiililaitteille, jotka eivät imaps:ää tukeneet – ja päästiin kaatuilleesta stunnelista eroon
  • läpinäkyvyyskin toimi: ihmisten ei tarvinnut tehdä muutoksia sähköpostiohjelmiensa asetuksiin, paitsi niiden, jotka käyttivät jotakin muuta kuin pääkäyttölupansa lyhyttä muotoa (tästä muutostarpeesta taas tiedotettiin kaikille Mappi-käyttäjille etukäteen, vaikka muita tunnusmuotoja ei ollutkaan virallisesti tuettu lähes kolmeen vuoteen)
  • systeemistä on saatu aikaan varsin kattava ylläpitodokumentti

Mitä nyt:

  • keskitettyä roskapostintunnistusta yhteispostilaatikoille pitäisi selvitellä
  • replikaklusteriin pitäisi myös lisätä muistia, että se olisi valmis vastaanottamaan koko käyttäjäkuorman, jos se joskus joudutaan sinne siirtämään – tarvittavat tiedostojärjestelmät siellä on jo olemassa, samoin kuin erikseen viritetty pää-postilaatikkotietokannan replikointi
  • ylläpitodokumenttia on pidettävä ajan tasalla
  • postilaatikon lisäkiintiöiden hinnat pitäisi päättää (esitys taitaa olla johtoryhmän käsittelyssä seuraavassa kokouksessa)
  • automaattisten poissaoloviestien eli ns. vacation-toiminnallisuuden selvittely on työn alla (siihen liittyy periaatetason ongelmia, jotka on mahdollisesti onnistuttu ratkaisemaan MIT:llä, mutta heistä ei ole ainakaan vielä kuulunut, kun kyselin)

Projekti on siirtynyt jälkitestausvaiheeseen, ja päättyy aikataulun mukaisesti vuoden lopussa. Tilanne alkaa jo nyt olla se, että uuden Mapin ylläpito on osa normaalia sähköpostiylläpitotoimintaa.

Valmis

Uusi systeemi on käytössä. Olkaapa hyvät.

Varmuuskopioajot aiheuttavat nyt iltasella vähän jumitusta. Katsotaan, miten tilanne kehittyy.

Synkronointia ja testausta

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.

Postit eivät katoa

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.

Siirtymä ja katko 13.-15. heinäkuuta

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.

Siirtymä lähestyy

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.

Klusterointia ja laitehankintoja

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.

Tiedotusta, virtualisointia, laitehankintojen suunnittelua

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.