Haamukuormituksesta

Aikanaan Mappia suunnitellessani olin ihmetellyt, mistä johtuu noin 11 tunnin syklillä kuormituskäyrissä näkyvä piikki, joka ei heijastu missään muissa kuormitusmittareissa kuin juurikin Linuxin loadissa. Sain lopulta selville, että se liittyy Red Hat Linuxin klusteritoteutuksen tiedostojärjestelmänkäsittelyskriptiin, ja jätin bugiraportin. Sen jälkeen olen elänyt haamukuormituksen kanssa – siitä ei ole ollut Mapin toiminnalle mitään muuta haittaa kuin se, että kuormituskäyrien seuraaminen on ollut hieman hankalampaa kuin ilman sitä olisi.

Taannoin tulikin sitten Red Hatin kehittäjiltä C:llä kirjoitettu korvausehdotus tiedostojärjestelmäntarkistus-skriptille. Asensin sen toissijaiseen klusteriin, ja voilá – tontunhatut (eli kuormapiikit) katosivat. Ehkä sekin saadaan laaduntarkkailusta läpi RHEL 5.2:een mennessä, niin sitten voisin ottaa sen mukaan myös ensisijaiseen klusteriin samalla, kun uuden LVM2:nkin. Ainahan sitä saa toivoa…

EVA-riippuvuuden ongelmia

Viime keskiviikkoiltana sain tekstiviestin: Mapissa on pahoja kuormitusongelmia. Niitä ei ollutkaan näkynyt sitten viime kesän.

Mistä oli kyse

  • Yksi Vallilan EVA-levyjärjestelmästä Mapille annetuista levyistä tapissa. Ilmeisesti juurikin tarkkaan sen ajan, kun muuan 250 gigan levyosiota siirrettiin EVAssa paikasta toiseen. Ja tämä taas oli ongelma, koska EVA-levyjärjestelmässä on ohjainta kohti vain 500 megatavua kirjoitusvälimuistia – se oli siis täynnä, joten Mapin suunnasta samalle ohjaimelle tulevat kirjoituspyynnöt hidastuivat.
  • Tämän vuoksi pääsy TLS-istuntovälimuistiin tietyilla Mappi-frontendeillä (p01,p02,p02) hidastui huomattavasti.
  • Tämän seurauksena Webmailin imapproxy (ilmeisesti) kyllästyi odottelemaan tls-kättelyn läpimenoa ja antoi IMPille FAILED LOGINnia.
  • Lopputuloksena ne käyttäjät, joille on Webmailissa konfiguroitu frontendiksi p01-p03, eivät päässeet sisään niin kauan kuin osion siirto kesti.
  • Ne käyttäjät, jotka käyttivät posti.mappi-osoitetta jollain muulla asiakasohjelmalla kuin Webmaililla, pääsivät kyllä sisään, mutta SSL/TLS-kättelyyn meni useita minuutteja.
  • Käyttäjillä, jotka lopulta pääsivät sisälle, esiintyi havaittavaa hidastelua; ei kuitenkaan vielä käyttökelvottomaksi tekevää (koska myös muut EVA-levyt hidastelivat; vastaavia pullonkauloja niihin ei kuitenkaan syntynyt).
  • Huomattavaa hidastelua esiintyi samaan aikaan myös Aleksandriassa: Netware-levyihin käsiksi pääseminen kesti ikuisuuden. Ongelma ei siis ollut Mappi- eikä edes Centos Linux -spesifinen.

Mitä asialle tehtiin

  • Siirsin Mappi-frontendien metadataosiot eri EVA-levyille, ettei kolme neljästä ainakaan väkisin ole samalla ohjaimella.
  • Poistin TLS-istuntovälimuistin käytöstä – välimuistista lienee ollut hyötyä lähinnä muutamalle käyttäjälle, ja sisäänkirjautumiseen liittyvä pullonkaula poistui.

Kun EVA-järjestelmässä seuraavana iltana siirrettiin yksi 320-gigainen osio paikasta toiseen, Mappi ei mennyt jumiin. Mutta siinä saattoi olla kyse siitäkin, että siirtoa oli hidastettu tarkoituksella, ettei se käyttäisi levyjärjestelmän koko kapasiteettia.

Mitä vielä tulevaisuudessa voidaan tehdä

  • Kunhan LVM2:n bugin n:o 252150 korjaus on saatu asennetuksi Mappi-koneisiin (ilmeisesti Centos 5.2:ssa joskus ensi kesänä), voidaan lopulta poistaa 28 ylimääräistä LVM:n fyysistä taltiota eli 28 ylimääräistä pientä EVA-levyä, jolloin EVA todennäköisesti hukkaa vähemmän kirjoitusvälimuistia, kun levyjäkin on vähemmän.

Päivityksiä

Tein sitten uhkailemani päivitykset tämän viikon keskiviikkona. Enimmäkseen meni ihan hyvin, mutta sitten ilmeni ongelma: Cyrus-parven edustakone versiolla 2.3.11 ja Webmailin käyttämä Imapproxy eivät toimi yhteen. Noin puolen tunnin päästä TLS-yhteyden muodostaminen ei enää onnistu. Jouduin siis palauttamaan edustakoneet versioon 2.3.8 (koska 2.3.10:stä ei ollut rpm:ää nopeasti saatavilla). Pitänee odottaa, kunnes bugi saadaan korjattua, ennen kuin päivittää edustakoneet.

Taustakoneet ja replikat ovat nyt joka tapauksessa versiossa 2.3.11, Simon Matterin RPM:stä suoraan (Simon oli lisännyt jakamaansa RPM:ään sen patchin, jonka olin joutunut aikaisempaan versioon lisäämään itse). Ja kaikkien koneiden käyttöjärjestelmä on päivitetty Centosin versioon 5.1. Yksittäisiä, satunnaisesti havaittuja parannuksia:

  • replikointiasiakas ei enää kaadu siihen, että se menettää yhteyden replikointipalvelimeen—sen sijaan isäntäprosessi huomaa tämän ja yrittää uutta yhteyttä vähän ajan päästä uudestaan
  • snmpd ei enää valita jatkuvasi jostain ia_addr-ongelmista, jotka ilmeisesti liittyivät ethernet-kanavasidontaan (channel bonding)

Tosiaan, jaottelin samassa yhteydessä palvelut uudestaan siten, että nykyään on kolme edusta- ja kolme taustakonetta. Palvelunseurantakäyristä päätellen tämä oli edullista: muisti ainakin riittää aikaisempaa paremmin, swäppäystä ei ole nää näkynyt lainkaan.

***

Dellinkin valokuitukortti oli saapunut joululoman aikana. Asensin sen tänään paikalleen Kumpulan klusterissa. Nyt minulla onkin sitten kaksi klusteria, joiden jokainen jäsen on sikäli tasaveroinen muiden kanssa, että näkee kaikki samat levylaitteet ja ajaa kaikkia samoja klusteri-infrastruktuurin osia. Tekee asioita, kuten levytaltioiden lisäämistä ja poistoa, huomattavasti entistä helpommaksi.

Klusterisolmuja ja päivityssuunnitelmia

Uusia klusterisolmuja tuotantokäytössä

Sain tämän viikon aikana tuotantoon Mappi-klusteriin ostetut uudet klusterisolmut. Käyttöjärjestelmänä on Centos 5.1, joka näyttäisi toimivan oikein nätisti osana Centos 5.0 -klusteria. Siirsin tiedekunta.mappi-palvelut uusille solmuille ja ajattelin katsoa, miltä näyttää—jos kuormitus pysyy tarpeeksi matalana, voisin siirtää niille myös posti.mappi-palvelut ja saada näin eriytetyksi frontendejä ajavat solmut backendejä ajavista solmuista.

Tiedekunta.mapit näyttävät muuten edelleen aiheuttavan noin puolet IMAP-liikenteestä. Uusilla klusterisolmuilla ei kuitenkaan näytä olevan mitään vaikeuksia selviytyä tästä, mikä on rohkaisevaa, kun tarkoitus olisi siirtää myös posti.mapit näille solmuille. Näin joulunalusviikolla liikenne tosin lie huomattavastikin normaalia vähäisempää—toisaalta, jos niikseen tulee, voitaisiin yksi nykyisistä backend-solmuista muuttaa frontend-solmuksi ja jakaa backend-palvelut tasan jäljellejäävien backend-solmujen kesken.

Päivitystestausta

Olen testannut testiklusterissa Centos 5.0 -versioisten solmujen päivitystä Centos 5.1:een. Hyvin sujuu: palvelut pois solmulta, klusterisoftat alas, päivitys, reboot, kuituajurin uudelleenkääntäminen ja initrd:n uudelleenmuodostus, reboot, klusterisoftat ylös, palvelut takaisin. Toimii.

Samoin olen testannut testiklusterissa Cyrus 2.3.8:n päivittämistä Cyrus 2.3.11:een. Hyvin näyttäisi toimivan sekin, samalla periaatteella eli palvelut pois tieltä, päivitys, palvelut takaisin. Ainoa asia, missä saa olla tarkkana, on se, että varsinainen backend-palvelu ja sitä vastaava replika ovat kaiken aikaa samaa versiota: jos yrittää replikoida 2.3.11-versiosta 2.3.8-versioon tai toisinpäin, syntyy hankaluuksia.

Testauksista rohkaistuneena aion päivittää koko tuotantoklusterin Centos 5.1:een ja Cyrus 2.3.11:een, kunhan ehdin lomalta takaisin. Tästä aiheutuvasta katkosta (2.1.) on tiedotettu normaaleja kanavia pitkin (noteksessa, uutisryhmässä, sähköpostilistalla, alman katkoilmoituksissa ja yhteispostilaatikossa).

Turhia frontendejä pois ja roskapostinsuodatusta päälle

Viimeisen parin viikon aikana aikaansaatua:

  • poistettu kasa turhia frontend-palveluita: kuormanjakoon poikkeustilanteissakin riittää aikeisempaa vähäisempi määrä, ja sitäpaitsi tiedekunta.mappi-palveluita pystyy yhdistämään useita saman cyrus-masterin hallinnoimiksi
  • bulletinboardeissa toimii roskapostinsuodatus ja automaattinen lajittelu junk-alikansioon alkaen tänään – kolmen viikon aikana vain kahden bulletinboardin ylläpitäjä kieltäytyi roskapostinlajittelusta

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.