Në një nga konferencat tona , e dedikuar planifikimit të infrastrukturës për implementimin e Zimbra Collaboration Suite në kompani, u tha se kufizimi kryesor në funksionimin e këtij zgjidhjeje është shpejtësia e hyrjes-daljes së pajisjeve disk në magazinat e postës. Në të vërtetë, në atë moment kur disa qindra punonjës të kompanisë aksesojnë një magazinë të njëjtë të postës në të njëjtën kohë, gjerësia e kanalit për shkruarjen dhe leximin e informacionit nga diskët mund të mos jetë e mjaftueshme për një funksionim reagues të shërbimit. Dhe nëse për instalime të vogla të Zimbra kjo nuk do të ishte një problem i madh, në rastin e kompanive të mëdha dhe ofruesve të SaaS, kjo mund të çojë në punë jo reaguese të postës elektronike dhe, si pasojë, në zvogëlimin e produktivitetit të punonjësve, si dhe në shkeljen e SLA. Prandaj, kur dizajnohet dhe operohet një instalim të madh të Zimbra, duhet kushtuar vëmendje të veçantë optimizimit të punës së diskëve në magazinat e postës. Le të shqyrtojmë dy raste dhe të provoni të kuptoni se cilat metoda optimizimi të ngarkesës në magazinat e diskëve mund të aplikohen në secilin prej tyre.
1. Optimizimi gjatë projektimit të një instalimi të madh të Zimbra
Në fazën e projektimit të një instalimi me ngarkesë të madhe të Zimbra, administratori i saj duhet të bëjë një zgjedhje se çfarë sistemi ruajtjeje të dhënash do të përdorë. Për t'u vendosur në këtë çështje, duhet të dihet se ngarkesa kryesore në diskët e fortë krijohet nga bazat e të dhënave MariaDB, sistemi i kërkimit Apache Lucene, si dhe ruajtja e objekteve BLOB. Prandaj, për funksionimin e këtyre produkteve softuerike nën kushte ngarkese të lartë, është e nevojshme të përdoren pajisje të shpejtë dhe të besueshme.
Në kushte normale, Zimbra mund të instalohet si në RAID të diskëve të fortë ashtu edhe në magazina të lidhura përmes protokollit NFS. Në rastet e instalimeve shumë të vogla, Zimbra mund të instalohet në një disk SATA të zakonshëm. Megjithatë, në kushtet e instalimeve të mëdha, të gjitha këto teknologji tregojnë disavantazhe të ndryshme në formën e shpejtësisë së ulët të shkruarjes ose besueshmërisë së ulët, që është e papranueshme as për kompanitë e mëdha dhe, më shumë, për ofruesit e SaaS.
Prandaj, nĂ« kushte infrastrukturore tĂ« mĂ«dha, Zimbra do tĂ« pĂ«rdorĂ« mĂ« sĂ« miri SAN. Kjo Ă«shtĂ« ajo qĂ« aktualisht mund tĂ« ofrojĂ« kapacitetin mĂ« tĂ« madh pĂ«r pajisjet e ruajtjes dhe, falĂ« mundĂ«sisĂ« pĂ«r tĂ« lidhur njĂ« numĂ«r tĂ« madh tĂ« caches, pĂ«rdorimi i saj nuk paraqet ndonjĂ« rrezik tĂ« rĂ«ndĂ«sishĂ«m pĂ«r ndĂ«rmarrjen. NjĂ« ide e mirĂ« Ă«shtĂ« pĂ«rdorimi i NVRAM-it, i cili pĂ«rdoret nĂ« shumĂ« SAN pĂ«r tĂ« ŃŃĐșĐŸŃuar punĂ«n gjatĂ« shkrimit. MegjithatĂ«, ndarja e shĂ«nimeve tĂ« dhĂ«nave tĂ« shkruara nĂ« vetĂ« diskĂ«t Ă«shtĂ« mĂ« mirĂ« tĂ« çaktivizohet, pasi mund tĂ« çojĂ« nĂ« dĂ«mtime tĂ« pakthyeshme tĂ« mediave dhe humbjen e tĂ« dhĂ«nave nĂ« rast tĂ« problemeve me energjinĂ«.
Sa i përket zgjedhjes së sistemit të skedarëve, zgjedhja optimale do të ishte përdorimi i standardeve për Linux, si Ext3/Ext4. Një detaj i rëndësishëm në lidhje me sistemin e skedarëve është se ai duhet të montohet me parametrin -noatime. Ky parametr do të çaktivizojë funksionimin e regjistrimit të kohës së fundit të aksesit në skedarë, duke reduktuar kështu ndjeshëm ngarkesën në lexim dhe shkrim. Në përgjithësi, kur krijoni sistemin e skedarëve ext3 ose ext4 për Zimbra, duhet të përdoren parametrat e mëposhtëm të utilitarit mke2fs:
-j â PĂ«r krijimin e njĂ« regjistri tĂ« sistemit tĂ« skedarĂ«ve Krijoni sistemin e skedarĂ«ve me njĂ« regjistĂ«r ext3/ext4.
-L EMRI â PĂ«r krijimin e emrit tĂ« volumit, nĂ« mĂ«nyrĂ« qĂ« mĂ« pas tĂ« pĂ«rdoret nĂ« /etc/fstab
-O dir_index â PĂ«r tĂ« pĂ«rdorur njĂ« pemĂ« kĂ«rkimi tĂ« hash-it pĂ«r tĂ« pĂ«rshpejtuar kĂ«rkimin e skedarĂ«ve nĂ« drejtoritĂ« e mĂ«dha
-m 2 â PĂ«r rezervimin e 2% tĂ« kapacitetit nĂ« sistemet e mĂ«dha tĂ« skedarĂ«ve pĂ«r katalogun themelor
-J size=400 â PĂ«r krijimin e njĂ« regjistri tĂ« madh
-b 4096 â PĂ«r pĂ«rcaktimin e madhĂ«sisĂ« sĂ« bllokut nĂ« byte
-i 10240 â PĂ«r ruajtjen e mesazheve, ky parametr duhet tĂ« pĂ«rputhet me madhĂ«sinĂ« pĂ«rmes mesatare tĂ« mesazheve. Duhet tĂ« jepet vĂ«mendje e madhe kĂ«tij parametri, pasi vlera e tij nuk mund tĂ« ndryshohet mĂ« vonĂ«
Përveç kësaj, rekomandohet të aktivizohet dirsync për ruajtjen e objekteve BLOB, ruajtjen e metadave të kërkimit Lucene dhe ruajtjen e radhës MTA. Kjo duhet bërë për shkak se zakonisht Zimbra përdor utilitarin fsync për regjistrimin e garantuar të blob-it me të dhëna në disk. Megjithatë, kur ruajtja postare Zimbra ose MTA krijojnë skedarë të rinj gjatë dërgimit të mesazheve, lind nevoja për regjistrimin në disk të ndryshimeve të ndodhura në dosjet përkatëse. Kjo është arsyeja pse, edhe në rastin kur skedari tashmë është regjistruar në disk me anë të fsync, regjistrimi i shtimit të tij në drejtoritë mund të mos arrijë të regjistrohet në disk dhe si rezultat mund të humbasë për shkak të një dështimi të papritur të serverit. Falë përdorimit të dirsync këtyre problemeve mund të shmangen.
2. Optimizimi me infrastrukturën Zimbra në punë
Shpesh ndodh që, pas disa vitesh përdorimi, numri i përdoruesve të Zimbra të rritet ndjeshëm dhe puna e shërbimit bëhet çdo ditë e më pak reaktive. Zgjidhja për këtë është e qartë: thjesht duhet të shtohen serverë të rinj në infrastrukturë, që shërbimi të funksionojë përsëri me shpejtësinë si më parë. Megjithatë, shpeshherë nuk ka mundësi të menjëhershme për të shtuar serverë të rinj në infrastrukturë për të rritur efikasitetin e saj. Shumë herë menaxherët IT detyrohen të miratojnë me gjatësi blerjen serverë të rinj me financat ose departamentin e sigurisë, për më tepër, shpeshherë dështojnë furnizuesit, të cilët mund të sjellin një server të ri me vonesë ose madje të sjellin atë që nuk është e nevojshme.
Sigurisht, është më mirë të ndërtohet infrastruktura e Zimbra me ndihmën e kapaciteteve të rezervuara, në mënyrë që gjithmonë të ketë rezerva për zgjerim dhe të mos mbahesh nga askush, megjithatë, nëse gabimi tashmë është bërë, menaxheri IT nuk ka alternativë tjetër veçse të minimizojë pasojat e tij. Për shembull, menaxheri IT mund të arrijë një rritje të vogël të performancës duke çaktivizuar përkohësisht shërbimet e sistemit Linux, të cilat gjatë punës rregullisht i qasen disqeve të forta dhe si pasojë mund të ndikojnë negativisht në shpejtësinë e punës së Zimbra. Kështu, për një kohë të mund të çaktivizohen:
autofs, netfs â ShĂ«rbimet e zbulimit tĂ« sistemeve tĂ« skedarĂ«ve tĂ« largĂ«t
cups â ShĂ«rbimi i printimit
xinetd, vsftpd â ShĂ«rbime tĂ« integruara *NIX, tĂ« cilat me siguri nuk do t'ju nevojiten
portmap, rpcsvcgssd, rpcgssd, rpcidmapd â ShĂ«rbimet e thirjes sĂ« procedurave tĂ« largĂ«ta qĂ« zakonisht pĂ«rdoren nĂ« lidhje me sistemet e skedarĂ«ve nĂ« rrjet
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap â Dublikatat e utilitareve kryesore tĂ« pĂ«rfshira 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Ă« sjellĂ« Probleme, prandaj kjo mund tĂ« bĂ«het manualisht gjatĂ« periudhave tĂ« ulĂ«ta tĂ« ngarkesĂ«s nĂ« serverĂ«.
Kursimi i burimeve sistemore si rezultat i çaktivizimit të këtyre shërbimeve nuk do të jetë shumë i rëndësishëm, por edhe kjo mund të jetë shumë e dobishme në kushte afër ngjarjeve të papritura. Pas shtimit të serverit të ri në infrastrukturën e Zimbra, rekomandohet që të aktivizohen përsëri shërbimet e çaktivizuara më parë.
gjithashtu, mund të optimizohet funksionimi i Zimbra duke transferuar shërbimin syslog në një server të veçantë, në mënyrë që gjatë funksionimit të tij të mos ngarkojë hard diskët e depozitave të postës. Për këto qëllime, mund të përdoret pothuajse çdo kompjuter, deri te një njësi e lirë si Raspberry Pi.
Burimi: habr.com
