Članek o Email.si

Meizu je 26. apr 2024 ob 00:24 izjavil:

Jebenti, dober spomin imaš za toliko časa nazaj. Dafak, jaz se toliko časa nazaj ne spomnem niti kaj sem jedel. Vsa čast.

Kaj sem jedel se ne spomnim niti za včeraj ... Moj spomin je na splošno bolj zmeden, posebej kar se tiče časovnic. Zapomnim pa si zadeve, za katere sem moral investirati kar nekaj energije v opazovanje, analiziranje, razumevanje in izboljševanje.

Nazaj na zgodbo ... post dot-com boom je še vedno prevladovala mentaliteta, da se web storitve zida na velikih škatlah (=vertikalno skaliranje). Tako smo se konec 2002 odločili za hitrejše (in rahlo večje) diskovno polje, zgrajeno iz jbod škatel in softverskega raida, ker za hardverskega nismo imeli budgeta.

V 2003 tako božiček prinese dve jbod fibrechannel škatli in 30 36gb 15k diskov iz neznanih virov. Zapregli smo ju na dva dual P3/800 serverja, vsak s po dvema qlogic 2gb fc karticama. Jbod škatle so bile dual ported, tako da smo lahko vzpostavili dve poti do vsakega diska. Takrat ni bilo še nobenih multipathd in takih reči, tako da je vse te IO čarovnije interno hendlal qlogic driver. Ob menjavi poti je linux kernel videl samo sekundo ali dve pavze na IOju, vse ostalo je ostalo enako. Super elegantna rešitev in nobenega kompliciranja v userspaceu. Admin je moral samo poskrbeti za dolgo vrstico primernih parametrov qlogic driverju v kernelu in vse je magično delovalo.

Diski so bili organizirani v stripe čez 15 mirrorjev, vsak s po enim diskom v eni škatli. Fotka tega setupa je v N1 članku. Gor sem glede na izkušnje ljudi s cyrus-imap mailing liste dal reiserfs, ki je takrat deloval res čudežno dobro s stotinami miljoni majhnih datotek. Na serverja smo dali redhat "advanced" server 2.1, to je verzija, ki se še ni imenovala rhel ;) HA failover, ki je bil na voljo v tej verziji, je bil res super in od vseh komplikacij si potreboval samo en serijski kabel med obema serverjema ter eno 1mb veliko particijo na enem skupnem disku; preko teh dveh metod sta se serverja tipala in preverjala stanje drug drugega, tako da je lahko pasivni prevzel diskovje in imapd, če se mu je zdelo, da aktivni ni več aktiven. Ta del setupa je deloval presenetljivo dobro in ni nikoli povzročil težav.

Diskovje sem seveda testiral z vsemi takrat dosegljivimi benchmarki in torture testi. V kakem tednu poganjanja testov sem videl samo en scsi error, ki sem ga iz sense kode dešifriral kot "internal sector relocation", kar je na novih diskih nekaj pričakovanega. Ni mi bilo jasno zgolj to, da je disk to sporočil kot hard error, kar je md raid smatral za no go in vrgel disk ven iz mirrorja. A ker je bil to osamljen dogodek, mu takrat nisem posvetil več časa.

Tako smo začeli planirati migracijo mail accountov. Ugasnit / skopirat / pognat bi verjetno trajalo tedne, zato smo takoj štartali na online migracijo. V živo sta se dogajali dve zadevi: migracija user accountov iz ldapa v mysql ter migracija iz starega imap serverja (sitke) na nov imap server. Hkrati smo takrat štartali z novim webmailom (jawmail), ki ga je spisal kolega, takrat še v osnovni šoli. Login vanj je imel dodano logiko, da je najprej probal novi backend in če userja tam ni našel, je sprožil migracijo. Ldap->mysql se je zgodil sinhrono, imap-to-imap pa se je šel v en home grown simple queue in se dogajal asinhrono, za čas kopiranja dostavljanje in prijavljanje v predal ni bilo mogoče. Na imap.email.si smo postavili imap proxy "perdition", ki se mu je dalo nakonfigurirati podobno logiko, tako da so bili istega tretmaja deležni tudi userji, ki niso uporabljali webmaila. Kot zanimivost, Perdition je kot hobi projekt spisal en poba iz ekipe LVS (linux virtual server), ki sem ga takrat v 2003 na Ottawa Linux Simposiumu tudi srečal in malo pokramljal z njim. Zanimivi časi :)

To so bili najboljši časi email.si. Jawmail je bil v primerjavi s horde imp svetlobna leta hitrejši, novi imap setup je bil tudi super hiter in vse je delovalo gladko. Mysql je na ločenem dual P3/800 serverju z dvema scsi diskoma gladko pumpal po več tisoč queryjev na sekundo, ne da bi si ob tem kvaril indexe, tako kot prej openldap. Poleg tega je bilo zelo enostavno dodajati nova polja v users tabelo z zanimivimi vrednostmi, iz katerih smo lahko začeli graditi razne statistike in monitoring v živo. Tako smo samo iz prijav odkrili, da imamo prek miljon prijav na dan in da vidimo v špicah po 60k unique userjev na uro. Kar hardcore številke za tisti čas, ni čudno, da so wannabe banner providerji klecali, ko smo jih vključili v naš login page ;)