Jukka hoiti tonttiani hyvin kuluneet kaksi vuotta; töihin paluu oli mukavaa, kun järjestelmä toimi kuin unelma. Ja kaikenlaisia hienoja uusia työkalujakin. Esimerkki: aikasarjaennuste siitä, miten sähköpostitaltioiden käyttöaste kehittyy.
Nykyisellä tilankäytön kasvutahdilla mennee siis noin kaksi vuotta, ennen kuin Mappi-järjestelmän levyjen täyttöaste alkaa nousta niin korkeaksi, että pitää alkaa harkita lisätilan hankkimista.
Yliopiston webmail on pitkään ollut Horde-projektin IMP. Pari vuotta sitten ohjelmisto päivitettiin uuteen versioon ja samalla laitteistoalusta uusittiin.
Uusi alusta muodostui kolmesta Xen-virtuaalikoneesta, joille hajautettiin käyttäjät IP-osoitteen perusteella. Ratkaisun piti olla riittävän tehokas, mutta vähän väliä virtuaalikoneille jouduttiin lisäämään muistia, jotta päästiin kasvattamaan Apachen MaxClients-arvoa. Silti käytetyin kolmesta koneesta oli aina välillä tukossa, eikä hajautuskaan toiminut parhaalla mahdollisella tavalla.
Päädyttiin sitten vapauttamaan Xen-alustaklusterin resurssit muuhun käyttöön, ja ostettiin kaksi tehomyllyä Webmailia pyörittämään. Idea on, että yksi kone hoitaa koko kuorman ja toinen on ns. cold standby, varakone, jonne koko kuorma voidaan siirtää millä tahansa hetkellä.
Koneet ovat tosiaan melko isoja: niissä on kaksi 6-ytimistä prosessoria ja 32 gigaa muistia. Juuri muisti on ollut Webmail-palvelinten kriittisin resurssi.
Käyttöönotto viime tiistaina sujui lähes ongelmitta ja sessiot synkattiin lennossa. Mutta hetken päästä uusikin palvelin oli jumissa. Missä vika? Kuormitustestauksessakaan ei käynyt ilmi, että kun todellinen käyttäjäkuorma iskee päälle, PHP-sessioiden kirjoittamista tehdään niin valtava määrä, että kiintolevyn nopeus ei vain riitä. Aiemmin levy oli tullut kertaluokkaa nopeammasta levyjärjestelmästä, nyt oli tilalla paikallista levyä ja kaikki kuorma yhdellä koneella.
Onneksi keskusmuistia oli niin reilusti, että siitä saatiin lohkaistua sessiodataa varten ramdisk-pala, minkä jälkeen levy-I/O-ongelma ratkesi kuin taikaiskusta.
Kiinnostavaa uudessa alustassa on lähinnä se, miten failover-tilanne hoidetaan: kone mainostaa reitittimelle itseään BGP-reititysprotokollaa käyttäen. Jos webmailin www-palveluosoitteen IP menee alas, katoaa reitti ko. IP:lle. Tällöin reititin ottaa käyttöön staattisen reitin, joka vie HTTP-pyynnöt varakoneelle. Softan nimi on Quagga. Elegantti ratkaisu kaikessa yksinkertaisuudessaan. Vain PHP-sessioiden synkkauksesta koneiden välillä täytyy huolehtia erikseen.
Mappilaatikoiden, niin henkilökohtaisten kuin jaettujenkin, kiintiöt kasvoivat gigaan juuri ennen joulua, 23.12. Joku käyttäjistähän saattoi pitää tätä jopa joululahjana, mutta ajoitus liittyy enemmänkin lomiin ja sensellaisiin. Kiintiöt kasvoivat heti kun levyä oli tarpeeksi.
Kiintiöiden kasvatusta edelsivät melkoiset levyalueiden ja tiedostojärjestelmien siirto-, järjestely- ja kasvatusoperaatiot (joista edellisessäkin postauksessa kerrotaan), jotka eivät kaikki menneet kuten piti. Sekundääriklusterin ongelmat, jotka pääasiassa johtuivat RedHat Cluster Suiten keskeneräisyydestä, eivät onneksi näkyneet käyttäjille. Primääriklusterissa sen sijaan oli joitakin lyhyitä katkoja, jotka näkyivät. Osa niistä oli suunniteltuja ja osa ei. Osa öiseen aikaan ja osa ei. Valitan.
Levykiintiöt yhteensä eli levytilan teoreettinen maksimikulutus on toki jotain aivan muuta kuin tarjolla olevan levyn tai varsinkin todellisen levynkulutuksen määrä. Yksittäiset käyttäjät eivät asiaa saa muuksi muutettua, mutta toki on tiedostettava, että jos kaikki käyttäjät tai merkittävä osa heistä päättäisi yhtäkkiä alkaa kunnolla täyttää postilaatikkoaan, helisemässä oltaisiin. Samaan tapaan kuin pankki, jonka asiakkaat yhtäkkiä päättäisivät nostaa säästötilinsä tyhjäksi. Käteinen loppuisi.
Asiaa havainnollistaa seuraava kuva. Vertaa myös edellisen postauksen kuvaan, jossa kiintiöiden kasvatus ei vielä näy.
Viimeisten viikkojen aikana on testattu levyalueiden siirtoa uuteen CLARiiON CX4 -levyjärjestelmään. Nyt siirrot näyttävät toimivan ja tätä kirjoittaessani puolitoista partitiota on jo siirretty.
Mappihan siis rakentuu siten, että Vallilassa on primääriklusteri, joka saa levyä HP:n EVA:sta, ja Kumpulassa sekundääriklusteri, jonne data replikoidaan, saa levynsä sikäläisestä EVA:sta, joka nyt siis korvataan toisella raudalla. Vallilan EVAa ei korvata, mutta sieltä siirtyy muuta käyttöä pois, joten Mappiin saadaan lisää levyä tätä kautta.
Näiden levyjärjestelyiden tarkoituksena on muun muassa toteuttaa johtoryhmän päätös, jonka mukaan levykiintiöt nostetaan yhteen gigatavuun. Tämä on tapahtumassa vielä tänä syksynä.
Eilinen lyhyt mutta suunnittelematon katko mappiautentikoinnissa liittyy tähän; primääriklusterin, jolle ei tältä osin ole vielä tehty mitään, autentikointipyynnöt ohjataan osittain sekundääriklusterin yhdelle palvelimelle, ja tämän palvelimen buuttaus sai valitettavasti käyttäjäntunnistuksen nikottelemaan. Sori!
PS.
Edellinen kirjoittaja Janne on virkavapaalla ja nyt puikoissa on Jukka Huhta. Toinen sähköpostiaiheinen (työ)blogini on Roskapuhetta. Sitäkin päivitellään harvakseltaan.
Mappi päivitettiin eilen illalla kello neljän ja kahdeksan välillä. Joitakin ongelmia esiintyi, mutta enimmäkseen päivitys sujui hyvin, ja asetetut tavoitteet saavutettiin.
Cyrus IMAPd:ssa on hieno MOTD-ominaisuus, joka näyttää käyttäjälle kirjautumisen yhteydessä IMAP ALERTina ylläpidon määrittelemän viestin, tyyliin “Palvelinta huolletaan. Jos INBOXisi näyttää tyhjältä, yritä kirjautua parin minuutin päästä uudestaan.” Tätä hyödyntämällä käyttöhäiriöistä tiedottaminen helpottuu huomattavasti, ja ylläpito päätyi siihen, että lyhyempi ennakkovaroitusaika riittää – katkoilmoitus (Notesin katkotietokantaan ja neuvojien postituslistalle) tehtiin saman päivän aikana kuin itse huoltokin.
Ainoa vain, että Cyruksen nykyisessä versiossa on ilmeisesti bugi: ALERT näytetään heti bannerin perään, ennen kuin yhteyttä ottava sähköpostiohjelma on ehtinyt sanoa mitään. Tästä on olemassa bugiraportti, mutta tällä erää näytti siltä, että useimmat tuetut sähköpostiasiakasohjelmat selviävät tilanteesta ja osaavat jopa näyttää MOTD:n oikein. (Sitä paitsi RFC on epäselvä tässä kohdin; Cyruksen toiminta saattaa olla ihan standardinmukaista.)
Testattuja asiakkaita:
Webmailin käyttämän Imapproxyn kanssa oli ongelmia, mutta ne kierrettin patchaamalla Imapproxy sopivasti. Näin testattuna ominaisuutta uskallettiin käyttää, ja huolto aloitettiin suunnitelmien mukaan kello neljältä.
Enimmäkseen katko sujui mukavasti, palvelut siirtyivät nätisti klusterisolmulta toiselle jne. Käyttöjärjestelmäpäivityksen yhteydessä kuitenkin myös käyttöjärjestelmäydin päivittyi, ja ilmeisesti jonkinlaisen moduuliepäyhteensopivuuden takia eräs uudelleenkäynnistetty klusterisolmu onnistui saamaan klusterin sisäisen viestiliikenteen jumiin ja klusteri hajosi osiinsa. Tämän ongelman purkamiseen meni kolme varttia kello 18.00-18.45, mutta sitten järjestelmä toimi taas.
Lisäksi kävi ilmi, että yhden käyttäjän Outlook Express (joka siis ei kuulu varsinaisesti tuettuihin sähköpostiasiakasohjelmiin) ei ollut selvinnyt IMAP ALERT -viestistä, ja käyttäjä ei ollut päässyt avaamaan INBOXiaan kello neljästä noin kello kahdeksaan – sisäänkirjautuminen toimi kyllä, ja käyttäjä sai kuulemma auki muut kansionsa. Lähetimme asiasta pahoittelut.
Joka tapauksessa useimmat käyttäjät näkivät vain lyhyitä katkoja (lukuunottamatta väliä 18.00-18.45), ja asetetut tavoitteet saavutettiin kaikki.
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…
Viime keskiviikkoiltana sain tekstiviestin: Mapissa on pahoja kuormitusongelmia. Niitä ei ollutkaan näkynyt sitten viime kesän.
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.
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:
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.
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.
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).
Viimeisen parin viikon aikana aikaansaatua:
University of Helsinki