Category: 1

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.

Tavoitteet

• edustakoneiden saaminen samaan versioon taustakoneiden kanssa
• DELETED-puun poistaminen käyttäjien näkyvistä
• viivästetysti poistettavien kansioiden poistaminen myös levyltä, ei vain Cyruksen kirjanpidosta
• SSL/TLS-jumitusten (ikuisesti roikkumaan jäävien yhteyksien) poisto
• kaikkien klusterisolmujen BIOS niin uudeksi, että suostuvat yhteistyöhön rautainfrastruktuurin kanssa

Tiedotus

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:

• Mozilla Thunderbird
• Mutt (joka ei näytä ALERTia, muttei kaadukaan siihen)
• Pine
• Outlook Office 2003

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ä.

Sujuminen

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.