Zimbra koostöösüsteemi postihoiu optimeerimine

Ühes meie eelnevas artiklis, mis käsitles infrastruktuuri planeerimist Zimbra Collaboration Suite'i rakendamisel ettevõttes, mainiti, et peamine piirang selle lahenduse kasutamisel on ketas seadmete sisendi ja väljundi kiirus postihoidlates. Tõepoolest, ajal, mil mitusada ettevõtte töötajat pääseb korraga samasse postihoidlasse, võib kõvakettalt andmete lugemise ja kirjutamise kanali laius osutuda ebapiisavaks teenuse reageerimisvõime tagamiseks. Kuigi väiksemate Zimbra paigalduste puhul ei pruugi see olla suur probleem, võivad suured ettevõtted ja SaaS-teenusepakkujad silmitsi seista aeglustunud e-posti töö ja seeläbi töötajate efektiivsuse vähenemisega, mis võiks põhjustada ka SLA rikkumise. Just sellepärast, et Zimbra suuremahuliste installatsioonide projekteerimisel ja haldamisel tuleks erilist tähelepanu pöörata kõvakettaseadmete töö optimeerimisele postihoidlates. Uurime kahte juhtumit ja proovime välja selgitada, milliseid failihoidlate koormuse optimeerimise meetodeid saab igas neist rakendada.

1. Suure Zimbra paigalduse optimeerimine projekteerimise etapis

Suure koormusega Zimbra paigalduse projekteerimisetapis peab administraator otsustama, millist andmesalvestussüsteemi kasutada. Selle küsimuse lahendamiseks tuleb teada, et peamine koormus kõvakettale tuleneb Zimbra Collaboration Suite'i koostisosadest, sealhulgas andmebaasist MariaDB, otsingusüsteemist Apache Lucene ning BLOB-objektide hoidlast. Seetõttu on nende tarkvaratoodete tõhusaks toimimiseks kõrge koormuse tingimustes oluline kasutada kiireid ja usaldusväärseid seadmeid.

Tavapärastes tingimustes saab Zimbra paigaldada nii RAID-kõvaketastele kui ka NFS-protokolli kaudu ühendatud salvestusruumidesse. Väga väikeste paigalduste puhul on Zimbra võimalik paigaldada ka tavalisele SATA-kettale. Kuid suurte paigaldiste puhul näitavad kõik need tehnoloogiad erinevaid puudusi, nagu kirjutamiskiirus või madal usaldusväärsus, mis ei ole vastuvõetavad ei suurtele ettevõtetele ega veelgi vähem SaaS-teenusepakkujatele.

Seetõttu on Zimbra suures infrastruktuuris kõige parem kasutada SAN-i. Just see suudab praegu tagada kõrgeima andmeedastuskiirus säilitusseadmetele ja tänu suure hulga vahemäluühenduste võimalusele on selle kasutamine praktiliselt vigadeta ettevõtte jaoks. Hea mõte on kasutada NVRAM-i, mida paljud SAN-id kasutavad kirjutamise kiirusel. Samas on parem keelata kirjutatavate andmete vahemälu samadesse ketastese, kuna see võib põhjustada andmed kahjustavad olukorrad ja andmete kaotuse toiteprobleemide korral.

Mis puutub failisüsteemi valikusse, siis parim valik on kasutada Linuxi standardseid Ext3/Ext4. Peamine nüanss, mis on seotud failisüsteemiga, on see, et seda tuleb mountida parameetriga -noatime. See parameeter keelab failide viimase ligipääsu aja fikseerimise funktsiooni, mis vähendab oluliselt lugemise ja kirjutamise koormust. Üldiselt tuleks Zimbra jaoks ext3 või ext4 failisüsteemi loomisel kasutada järgmisi parameetreid utiliidile mke2fs:

-j — Failisüsteemi ajalugu loomise jaoksCreate the file system with an ext3/ext4 journal.
-L NIMI — Mahuni pealkirja loomiseks, et hiljem kasutada seda /etc/fstab-s
-O dir_index — Otsingufailide kiirendamiseks suurtes kataloogides hashmuude puu kasutamiseks
-m 2 — 2% reserveerimise reservi seadistamiseks suurtel failisüsteemidel juurkatalooge jaoks
-J size=400 — Suure ajalugu loomise jaoks
-b 4096 — Bloki suuruse määramiseks baitides
-i 10240 — Sõnumite salvestamiseks peab see parameeter vastama keskmisele sõnumi suurusele. Tuleb sellele parameetrile tähelepanu pöörata, kuna hiljem pole selle väärtust võimalik muuta

Lisaks soovitatakse sisse lülitada dirsync BLOB-objektide talletamiseks, Lucene'i metaandmete otsingutalleteks ja MTA järjekordade talletamiseks. Seda peaks tegema sellepärast, et tavaliselt kasutab Zimbra utiliiti fsync andmete blobide tagamiseks kettale. Kuid kui Zimbra postikarp või MTA loob uusi faile sõnumite edastamise ajal, tekib vajadus nende vastavate kaustade kettale tehtud muudatuste salvestamiseks. Just seetõttu, et isegi olukordades, kus fail on juba kettale salvestatud, võib tema lisamisteave kaustades mitte jõuda kettale ning seetõttu võib see ootamatu serveri rikke tõttu kaduma minna. Tänu fsyncnende probleemide vältimisele on võimalik. dirsync 2. Optimeerimine töötava Zimbra infrastruktuuri korral

Tihti juhtub, et pärast Zimbra kasutamise mitmeid aastaid suureneb selle kasutajate arv märgatavalt ja teenuse töö muutub iga päevaga järjest vähem reageerivaks. Välja pääsemine sellisest olukorrast on ilmne: tuleb lihtsalt lisada infrastruktuuri uusi servereid, et teenus töötaks taas sama kiiresti kui varem. Samas ei ole alati võimalik kohe lisada uusi servereid, et parandada selle jõudlust. Tihti peavad IT-juhid kaua kokku leppima

uusserverites raamatupidamisega või turbosakonnaga, lisaks ei suuda sageli tarnijad, kes võivad uue serveri pärast aega juurde tuua või toimetavad hoopis vale seadme. Muidugi on kõige parem ehitada oma Zimbra infrastruktuur varuga, et alati oleks ruumi selle laiendamiseks ja ei sõltuks kellestki, kuid kui viga on juba tehtud, jääb IT-juhile vaid tagajärgede leevendamisele keskenduda. Näiteks võib IT-juht saavutada väikese jõudluse kasvu ajal, kui ajutiselt välja lülitati Linuxi süsteemiteenused, mis töötamise ajal pidevalt kõvakettale pöördusid ja seetõttu võivad Zimbra töö kiirus mõjutada. Näiteks võib mõneks ajaks välja lülitada:

autofs, netfs

— Kaugfailisüsteemide avastamise teenused cups
— Printimisteenus xinetd, vsftpd
— Sisemised *NIX teenused, mis tõenäoliselt ei ole 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 põhivahendite dubleerimine slocate/updatedb
slocate/updatedb Kuna Zimbra salvestab iga sõnumi eraldi failina, võib igapäevane updatedb teenuse käivitamine tekitada probleeme, seetõttu on soovitatav seda teha käsitsi serverite kõige väiksema koormuse ajal.

Kuna teenuste väljalülitamise tõttu saadav süsteemsete ressursside kokkuhoid ei ole kuigi suur, võib isegi see olla märkimisväärne kriitilistes olukordades. Pärast uue serveri lisamist Zimbra infrastruktuuri on soovitatav uuesti lubada varasemalt välja lülitatud teenused.

Zimbra tööd on võimalik optimeerida, viies syslog teenuse eraldi serverisse, et see ei koormaks postide salvestusseadmeid töö ajal. Selle jaoks sobib praktiliselt ükskõik milline arvuti, alates odavast üheinimesest Raspberry Pi-st.

Allikas: habr.com