Optimizimi i funksionimit të depozitave të postës në Zimbra Collaboration Suite

Në një prej dokumenteve tona që trajton planifikimin e infrastrukturës për implementimin e Zimbra Collaboration Suite në një kompani, u theksua se kufizimi kryesor në funksionimin e këtij zgjidhjeje është shpejtësia e hyrjes dhe daljes së pajisjeve disk në depozitat postare. Në të vërtetë, kur disa qindra punonjës të kompanisë aksesojnë një depozitë të vetme postare në të njëjtën kohë, gjerësia e kanalit për të shkruar dhe lexuar informacionin nga disqet e ashardhës mund të mos jetë e mjaftueshme për një funksionim reagues të shërbimit. Ndërsa për instalimet e vogla të Zimbra nuk do të përbënte një problem të veçantë, për kompanitë e mëdha dhe ofruesit e shërbimeve SaaS, kjo mund të çojë në funksionim të pandjeshëm të postës elektronike dhe si pasojë, në uljen e efikasitetit të punonjësve, përveç shkeljes së SLA-së. Prandaj, gjatë projektimit dhe operimit të instalimeve të mëdha të Zimbra, është e rëndësishme të kushtohet vëmendje të veçantë optimizimit të funksionimit të disqeve në depozitën postare. Le të shqyrtojmë dy raste dhe të përpiqemi të zbulojmë se cilat metoda të optimizimit të ngarkesës në depozitat diskore mund të aplikohen në secilin prej tyre. artikujt e kaluar, e cila për planifikimin e infrastrukturës gjatë zbatimit të Zimbra Collaboration Suite në një ndërmarrje, u tha se kufizimi kryesor i përdorimit të këtij zgjidhjeje është shpejtësia e input-output të pajisjeve të diskut në depozitat e postës elektronike. Në të vërtetë, në ato momente kur qindra punonjës të një ndërmarrjeje aksesojnë një depozitë të përbashkët postare, gjerësia e kanalit për shkrimin dhe leximin e informacionit nga diskët e ngurtë mund të mos jetë e mjaftueshme për një funksionim të shpejtë të shërbimit. Edhe pse për instalimet e vogla të Zimbra kjo mund të mos jetë një problem i madh, në rastin e ndërmarrjeve të mëdha dhe ofruesve të SaaS kjo mund të çojë në një funksionim të ngadalësuar të postës elektronike dhe, si pasojë, në uljen e efikasitetit të punonjësve, si dhe në shkelje të SLA. Kjo është arsyeja pse, gjatë projektimit dhe operimit të instalimeve masive të Zimbra, duhet t'u kushtohet vëmendje të veçantë optimizimit të punës së diskëve në depozitën e postës. Le të shqyrtojmë dy raste dhe të përpiqemi të zbulojmë cilat metoda optimizimi mund të aplikohet për ngarkesat në depozitat e diskëve në çdo rast.

Optimizimi i funksionimit të depozitave të postës në Zimbra Collaboration Suite

1. Optimizimi në fazën e projektimit të një instalimi të madh Zimbra

Në fazën e projektimit të një instalimi Zimbra me ngarkesë të lartë, administratori i saj duhet të vendosë se cilin sistem ruajtjeje do të përdorë. Për të marrë një vendim rreth kësaj çështjeje, është e rëndësishme të dihet se ngarkesa kryesore në disqet e ashardhës shkaktohet nga sistemet e menaxhimit të të dhënave MariaDB, sistemi i kërkimit Apache Lucene, si dhe depozita e objekteve BLOB të Zimbra Collaboration Suite. Prandaj, për funksionimin e këtyre produkteve software nën kushte ngarkese të lartë, duhet të përdoren pajisje të shpejta dhe të besueshme.

Në kushte normale, Zimbra mund të instalhet si në RAID nga disqet e ashardhës, ashtu edhe në depozita të lidhura nëpërmjet protokollit NFS. Në raste të instalimeve shumë të vogla, mund të instalohet Zimbra në një disk të zakonshëm SATA. Megjithatë, në kushte të instalimeve të mëdha, të gjitha këto teknologji tregojnë disavantazhe të ndryshme siç janë shpejtësi e ulët shkruese ose besueshmëri të ulët, që nuk janë të pranueshme as për kompanitë e mëdha, e lëre më për ofruesit e shërbimeve SaaS.

Prandaj, në kushtet e infrastrukturave të mëdha Zimbra, është më së miri të përdoret SAN. Ajo aktualisht është e aftë të ofrojë kapacitetin më të lartë për pajisjet e ruajtjes dhe, falë mundësisë për lidhje me një sasi të madhe cache, përdorimi i saj praktikisht nuk ka rreziqe të rëndësishme për kompaninë. Një ide e mirë është përdorimi i NVRAM, e cila përdoret në shumë SAN për të përshpejtuar funksionimin gjatë shkrimit. Mirëpo, caching i të dhënave të shkruara në diskët e vetë është më mirë të çaktivizohet, pasi kjo mund të çojë në dëmtime fatale të mediave dhe humbje të të dhënave në rast të problemeve me furnizimin me energji.

Sa i përket zgjedhjes së sistemit të skedarëve, zgjedhja optimale do të ishte të përdoret standardi Linux Ext3/Ext4. Një nuancë kryesore lidhur me sistemin e skedarëve është se ai duhet të montehet me parametrin -noatime. Ky parametr do të çaktivizojë funksionin e regjistrimit të kohës së fundit që është aksesuar skedari, dhe, si pasojë, do të reduktojë ndjeshëm ngarkesën e leximit dhe shkrimit. Në përgjithësi, kur krijoni një sistem skedarësh ext3 ose ext4 për Zimbra, duhet të përdoren parametrat e mëposhtëm të utilit mke2fs:

-j — PĂ«r tĂ« krijuar njĂ« regjistĂ«r tĂ« sistemit tĂ« skedarĂ«ve Krijo sistemin e skedarĂ«ve me njĂ« regjistĂ«r ext3/ext4.
-L EMRI — PĂ«r tĂ« krijuar njĂ« emĂ«r volume, pĂ«r ta pĂ«rdorur mĂ« vonĂ« nĂ« /etc/fstab
-O dir_index — PĂ«r tĂ« pĂ«rdorur njĂ« pemĂ« kĂ«rkimi tĂ« hash pĂ«r tĂ« pĂ«rshpejtuar kĂ«rkimin e skedarĂ«ve nĂ« direktorĂ«t e mĂ«dhenj
-m 2 — PĂ«r tĂ« rezervuar 2% tĂ« volumit nĂ« sistemet e skedarĂ«ve tĂ« mĂ«dha pĂ«r katalogun rrĂ«njĂ«
-J size=400 — PĂ«r tĂ« krijuar njĂ« regjistĂ«r tĂ« madh
-b 4096 — PĂ«r tĂ« caktuar madhĂ«sinĂ« e bllokut nĂ« byte
-i 10240 — PĂ«r depozitat e mesazheve ky parametr duhet tĂ« pĂ«rputhet me madhĂ«sinĂ« mesatare tĂ« mesazheve. Duhet tĂ« kushtohet vĂ«mendje tĂ« veçantĂ« kĂ«tij parametri, pasi pas kĂ«saj vlera e tij nuk do tĂ« mund tĂ« ndryshohet.

Përveç kësaj, rekomandohet të aktivizohet dirsync për depozitat e objekteve BLOB, depozitat e metadatat e kërkimit Lucene dhe depozitat e radhës MTA. Duhet bërë kështu sepse zakonisht Zimbra përdor utilitarin fsync për të garantuar shkarkimin e blob-it të të dhënave në disk. Megjithatë, kur depozita postare e Zimbra ose MTA krijon skedarë të rinj gjatë dorëzimit të mesazheve, lind nevoja për të shkruar në disk ndryshimet që kanë ndodhur në direktorët përkatës. Prandaj, edhe në rastin kur një skedar është regjistruar tashmë në disk me fsync, regjistrimi i saj në drejtoritë mund të mos arrijë të shkruhet në disk dhe si rezultat mund të humbasë për shkak të një dështimi të papritur të serverit. Duke përdorur dirsync këto probleme mund të shmangen.

2. Optimizimi me infrastrukturën e funksionuar Zimbra

Shpesh ndodh që pas disa viteve eksploatimi, numri i përdoruesve të Zimbra rritet ndjeshëm dhe funksionimi i shërbimit bëhet çdo ditë e më pak reagues. Zgjidhja për këtë situatë është e qartë: thjesht duhet të shtohen serverë të rinj në infrastrukturë, që shërbimi të funksionojë po aq shpejt sa më parë. Ndërkohë, nuk është gjithmonë e mundur të shtohen menjëherë serverë të rinj në infrastrukturë për të rritur performancën e saj. Shpesh menaxherët IT duhet të kalojnë shumë kohë duke miratuar blerjen serverët e rinj me kontabilitetin apo departamentin e sigurisë, përveç kësaj, shpesh ndodhin probleme me ofruesit që mund të sjellin serverin e ri me vonesë ose madje të sjellin diçka që nuk është e nevojshme.

Natyrisht, më e mira është të ndërtohet infrastruktura Zimbra me një rezervë, për të pasur gjithmonë një kapacitet për zgjerim dhe për të mos u varur nga askush, megjithatë, nëse gabimi tashmë është bërë, menaxherit IT i mbetet vetëm të zbutë pasojat sa më shumë që mundet. Për shembull, menaxheri IT mund të arrijë një rritje të vogël të performancës duke fikur përkohësisht shërbimet sistemore Linux, të cilat gjatë punës i qasen rregullisht disqeve të forta dhe për këtë arsye mund të ndikojnë negativisht në shbrim e Zimbra. Pra, përkohësisht mund të fikni:

autofs, netfs — ShĂ«rbimet e zbulimit tĂ« sistemeve tĂ« skedarĂ«ve tĂ« largĂ«t
cups — ShĂ«rbimi i printimit
xinetd, vsftpd — ShĂ«rbimet e integruara *NIX, tĂ« cilat ndoshta nuk do t'ju duhen
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — ShĂ«rbime tĂ« thirrjeve tĂ« largĂ«ta tĂ« procedurave, tĂ« cilat zakonisht pĂ«rdoren nĂ« kombinim me sistemet e skedarĂ«ve nĂ« rrjet
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — Duplicatet e utiliteteve kryesore qĂ« bĂ«jnĂ« pjesĂ« nĂ« Zimbra Collaboration Suite
slocate/updatedb — Duke qenĂ« se Zimbra ruan çdo mesazh nĂ« njĂ« skedar tĂ« veçantĂ«, ekzekutimi i pĂ«rditshĂ«m i shĂ«rbimit updatedb mund tĂ« shkaktojĂ« probleme, dhe pĂ«r kĂ«tĂ« arsye mund tĂ« bĂ«het manualisht gjatĂ« periudhave me ngarkesĂ« mĂ« tĂ« ulĂ«t nĂ« server

Kursimi i burimeve sistemore nga fikja e këtyre shërbimeve do të jetë jo shumë i dukshëm, por megjithatë, kjo mund të ndihmojë shumë në kushte të ngjashme me forcat madhore. Pasi të shtohet serveri i ri në infrastrukturën Zimbra, rekomandohet që përsëri të aktivizohen shërbimet e fikura më parë.

Gjithashtu, mund të optimizohet puna e Zimbra duke e transferuar shërbimin syslog në një server të veçantë, që gjatë punës të mos ngarkojë disqet e forta të depozitave të postës. Për këto qëllime, pothuajse çdo kompjuter, deri te një single-board computer i lirë si Raspberry Pi, do të ishte i përshtatshëm.

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster