E-postihoiustamise töö optimeerimine Zimbra Collaboration Suite'is

Ühes meie eelnevatest artiklitest, mis käsitleb infrastruktuuri planeerimist Zimbra Collaboration Suite'i juurutamisel, märgiti, et peamine piirang selle lahenduse tööks on andmekandjate sisend-väljundite kiirus postikogudes. Tõepoolest, olukordades, kus sadakond töötajat pöördub sama postikogu poole, võib andmeedastuskiirus kõvaketastelt olla ebapiisav teenuse vastupidavaks toimimiseks. Kuigi väikestes Zimbra seadmetes ei teki see suur probleem, siis suurte ettevõtete ja SaaS-teenuse pakkujate puhul võib see viia e-posti aeglase töötamiseni, mille tagajärjeks on töötajate efektiivsuse langus ja SLA rikkumine. Seetõttu tuleb Zimbra suuremahuliste seadete projekteerimisel ja käitamisel pöörata erilist tähelepanu kõvaketaste töö optimeerimisele postikogudes. Vaatame kahte juhtumit ja püüame välja selgitada, milliseid optimeerimisvõtteid andmekogude koormuse vähendamiseks saab igas neist rakendada.

1. Suure mahutavusega Zimbra paigaldamise optimeerimine

Kuna Zimbra suure koormusega paigalduse kavandamise etapis peab administraator valima, millist andmesalvestussüsteemi kasutada. Selle küsimuse lahendamiseks on oluline teada, et peamine koormus HDD-dele pärineb Zimbra Collaboration Suite'i andmebaasist MariaDB, otsingusüsteemist Apache Lucene ja BLOB-objektide salvestamisest. Seetõttu on nende tarkvaratoodete töötamiseks kõrge koormusega tingimustes vajalik kasutada kiiret ja usaldusväärset riistvara.

Tavalistes tingimustes saab Zimbat paigaldada nii RAID-kõvakettadele kui ka NFS-protokolli kaudu ühendatud salvestuslahendustele. Väikestes paigaldustes on võimalik Zimbra paigaldada ka tavalisele SATA-kettale. Kuid suurte paigaldiste korral näitavad kõik need tehnoloogiad erinevaid puudusi, näiteks madalam kirjutamiskiirus või madal usaldusväärsus, mis ei ole vastuvõetav suurettevõtetele ega veel enam SaaS-teenuse pakkujatele.

Seetõttu on Zimbra ulatuslike infrastruktuuride tingimustes parim kasutada SAN-i. See suudab praegu pakkuda suurimat läbilaskevõimet salvestusseadmete jaoks ning tänu suure arvu vahemälu ühendamise võimalusele toob selle kasutamine ettevõttele praktiliselt nullriski. Hea idee on kasutada NVRAM-i, mida kasutatakse paljudes SAN-ides, et kiirendada kirjutamise ajal. Küll aga on soovitatav keelata kirjutatavate andmete vahemälu kogumine ketastel, kuna see võib põhjustada pöördumatut kahjustumist ja andmete kaotust toiteprobleemide korral.

Mis puudutab failisüsteemi valikut, siis parim valik on kasutada Linuxi standardseid Ext3/Ext4. Peamine nüanss failisüsteemis on see, et see tuleks monteerida parameetriga -noatime. See seade keelab viimase faili juurde pääsemise aja fikseerimise, mis oluliselt vähendab lugemise ja kirjutamise koormust. Üldiselt peaks Zimbra failisüsteemi ext3 või ext4 loomisel kasutama järgmisi utiliidi parameetreid. mke2fs:

-j — Failisüsteemi loomine ext3/ext4 päevikuga.
-L NIMI — Mahu nime loomiseks, et hiljem kasutada seda /etc/fstab.
-O dir_index — Failide otsingu kiirendamiseks suuremates kataloogides kasutada hash-puu.
-m 2 — 2% maht reserveerida suurte failisüsteemide jaoks juurkatalooge.
-J size=400 — Suure päeviku loomiseks.
-b 4096 — Bloki suuruse määramiseks baitides.
-i 10240 — Sõnumite salvestamiseks peab see parameeter vastama sõnumite keskmisele suurusele. Selle parameetri määratlemisele tuleb tähelepanu pöörata, kuna hiljem ei saa seda muutuda.

Lisaks soovitatakse lubada dirsync BLOB-objektide, Lucene'i metaandmete otsingutalituse ja MTA järjekorra salvestamiseks. Seda tuleb teha, kuna tavaliselt kasutab Zimbra utiliiti. fsync andmete blob garantitud salvestamiseks kettale. Siiski, kui Zimbra postihaldussüsteem või MTA loob uusi faile sõnumite tarnimise ajal, tekib vajadus salvestada kettale muudatused, mis on toimunud vastavates kaustades. Just seetõttu, et isegi juhul, kui fail on juba kettale salvestatud, võib teave selle lisamisest direktori sissehelistamisele mitte jõuda ja seetõttu võib see ootamatute serveri tõrgete tõttu kaduma minna. fsyncnende probleemide vältimiseks. dirsync 2. Zimbra töötava infrastruktuuri optimeerimine

Tihti juhtub, et pärast Zimbra kasutamise mitut aastat suureneb kasutajate arv märkimisväärselt ja teenuse töö on iga päevaga üha vähem vastutulelik. Lahendus ei ole keeruline: tuleb lihtsalt infrastruktuurile lisada uusi servereid, et teenus töötaks taas sama kiiresti nagu varem. Samas ei ole alati võimalik kohe lisada uusi servereid, et suurendada infrastruktuuri jõudlust. Sageli peavad IT-juhid pikalt kooskõlastama

Tihti juhtub, et pärast mitut aastat Zimbra kasutamist kasvab kasutajate arv oluliselt ja teenuse toimimine muutub iga päevaga järjest vähem vastutulelikuks. Lahendus sellele probleemile on selge: tuleb lihtsalt lisada uusi servereid infrastruktuuri, et teenus töötaks taas sama kiiresti kui varem. Samas ei ole alati võimalik kohe lisada uusi servereid infrastruktuuri, et parandada selle jõudlust. Sageli peavad IT-juhid pikka aega kooskõlastama uute serverite ostmist. uute serverite soetamist. raamatupidamise või turbeosakonnaga, lisaks toovad sageli pettuseid ka tarnijad, kes võivad uue serveri hilja toimetada või tuua täiesti vale toote.

Muidugi on parim üles ehitada oma Zimbra infrastruktuuri varuga, et alati oleks ruumi laiendamiseks ja mitte kellelegi sõltuda, kuid kui viga on juba tehtud, jääb IT-juhile vaid maksimaalselt siluda selle tagajärgi. Näiteks võib IT-juhik saavutada väikese jõudluse kasvu, kasutades ajutist Linuxi süsteemiteenuste väljalülitamist, mis töötamise käigus pidevalt kõvakettale pöördub ja seetõttu võib negatiivselt mõjutada Zimbra tööd. Näiteks võib ajutiselt välja lülitada:

autofs, netfs — Kaugfailisüsteemide avastamise teenused
cups — Printimisteenus
xinetd, vsftpd — Sisseehitatud *NIX teenused, mis tõenäoliselt ei ole teile vajalikud
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Kaugprotseduuride teenused, mida tavaliselt kasutatakse koos võrgufailisüsteemidega
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — Zimbra Collaboration Suite'i kuuluvate põhiteenuste koopiad
slocate/updatedb — Kuna Zimbra salvestab iga sõnumi eraldi failina, võivad iga päev käivitatavad updatedb teenused tekitada probleeme, seega võib seda teha käsitsi kõige väiksema koormuse ajal serverites.

Süsteemiressursside säästmine nende teenuste väljalülitamise kaudu ei ole väga märkimisväärne, kuid isegi see võib osutuda äärmiselt kasulikuks kriitilistes olukordades. Pärast uue serveri lisamist Zimbra infrastruktuuri on soovitatav uuesti lubada eelnevalt välja lülitatud teenused.

Zimbra töö efektiivsust saab samuti optimeerida, viies syslog teenuse eraldi serverisse, et see ei koormaks meilisüsteemide kõvakettasid töötamise ajal. Selleks sobib praktiliselt iga arvuti, sealhulgas odav üheplaadina Raspberry Pi.

Allikas: habr.com