Në njërën tonë , kushtuar planifikimit të infrastrukturës gjatë zbatimit të Zimbra Collabortion Suite në një ndërmarrje, u tha se kufizimi kryesor në funksionimin e kësaj zgjidhjeje është shpejtësia hyrëse/dalëse e pajisjeve të diskut në ruajtjet e postës. Në të vërtetë, në një kohë kur disa qindra punonjës të një ndërmarrje hyjnë njëkohësisht në të njëjtën ruajtje të postës, gjerësia e kanalit për shkrimin dhe leximin e informacionit nga disqet e ngurtë mund të mos jetë e mjaftueshme për funksionimin e përgjegjshëm të shërbimit. Dhe nëse për instalimet e vogla të Zimbra kjo nuk do të jetë një problem i veçantë, atëherë në rastin e ndërmarrjeve të mëdha dhe ofruesve të SaaS, e gjithë kjo mund të çojë në email që nuk përgjigjen dhe, si rezultat, një ulje të efikasitetit të punonjësve, si dhe një shkelje të SLA-ve. Kjo është arsyeja pse, gjatë projektimit dhe funksionimit të instalimeve në shkallë të gjerë Zimbra, vëmendje e veçantë duhet t'i kushtohet optimizimit të performancës së hard diskeve në ruajtjen e postës. Le të shohim dy raste dhe të përpiqemi të zbulojmë se cilat metoda për optimizimin e ngarkesës në ruajtjen e diskut mund të aplikohen në secilën prej tyre.
1. Optimizimi gjatë projektimit të një instalimi Zimbra në shkallë të gjerë
Gjatë fazës së projektimit të një instalimi Zimbra me ngarkesë të lartë, administratori do të duhet të zgjedhë se cilin sistem ruajtjeje do të përdorë. Për të vendosur për këtë çështje, duhet të dini se ngarkesa kryesore në disqet e ngurtë vjen nga MariaDB DBMS e përfshirë në Zimbra Collaboration Suite, motori i kërkimit Apache Lucene dhe ruajtja e blobit. Kjo është arsyeja pse për të përdorur këto produkte softuerike në kushte të ngarkesës së lartë, është e nevojshme të përdoren pajisje me shpejtësi të lartë dhe të besueshme.
Në kushte normale, Zimbra mund të instalohet si në RAID të disqeve të ngurtë ashtu edhe në ruajtje të lidhur nëpërmjet protokollit NFS. Për instalime shumë të vogla, mund të instaloni Zimbra në një disk të rregullt SATA. Megjithatë, në kontekstin e instalimeve të mëdha, të gjitha këto teknologji demonstrojnë disavantazhe të ndryshme në formën e shpejtësisë së reduktuar të regjistrimit ose besueshmërisë së ulët, gjë që nuk është e pranueshme as për ndërmarrjet e mëdha dhe as, veçanërisht për ofruesit e SaaS.
Kjo është arsyeja pse në infrastrukturat Zimbra në shkallë të gjerë është më mirë të përdorni një SAN. Është kjo teknologji që aktualisht është e aftë të sigurojë xhiron më të madhe për pajisjet e ruajtjes dhe në të njëjtën kohë, falë aftësisë për të lidhur një sasi të madhe të cache, përdorimi i saj praktikisht nuk paraqet ndonjë rrezik të rëndësishëm për ndërmarrjen. Është një ide e mirë të përdorni NVRAM, i cili përdoret në shumë SAN për të shpejtuar gjërat gjatë shkrimeve. Por është më mirë të çaktivizoni memorien e të dhënave të regjistruara në vetë disqet, pasi mund të çojë në dëmtime të pariparueshme në media dhe humbje të të dhënave nëse ndodhin probleme me energjinë.
Sa i përket zgjedhjes së një sistemi skedarësh, zgjidhja më e mirë do të ishte përdorimi i standardit Linux Ext3/Ext4. Nuanca kryesore e lidhur me sistemin e skedarëve është se ai duhet të montohet me parametrin - noatime. Ky opsion do të çaktivizojë funksionin e regjistrimit të kohës së hyrjes së fundit në skedarë, që do të thotë se do të zvogëlojë shumë ngarkesën në lexim dhe shkrim. Në përgjithësi, kur krijoni një sistem skedari ext3 ose ext4 për Zimbra, duhet të përdorni parametrat e mëposhtëm të shërbimeve mke2fs:
-j — Për të krijuar një ditar të sistemit të skedarëve Krijoni sistemin e skedarëve me një ditar ext3/ext4.
-L EMRI - Për të krijuar një emër vëllimi për ta përdorur më pas në /etc/fstab
-O dir_index - Për të përdorur një pemë kërkimi të hashuar për të shpejtuar kërkimet e skedarëve në drejtoritë e mëdha
- 2 m — Për të rezervuar 2% të vëllimit në sistemet e skedarëve të mëdhenj për direktoriumin rrënjë
-Madhësia J=400 — Për të krijuar një revistë të madhe
-b 4096 — Për të përcaktuar madhësinë e bllokut në bajt
-i 10240 - Për ruajtjen e mesazheve, ky cilësim duhet të korrespondojë me madhësinë mesatare të mesazhit. Ju duhet t'i kushtoni vëmendje këtij parametri, pasi vlera e tij nuk mund të ndryshohet më vonë.
Rekomandohet gjithashtu të aktivizoni disinkronizoj për ruajtjen e blobit, ruajtjen e meta të dhënave të kërkimit Lucene dhe ruajtjen e radhës MTA. Kjo duhet të bëhet sepse Zimbra zakonisht përdor programin fsync për shkrimin e garantuar të një blob me të dhëna në disk. Megjithatë, kur dyqani i postës Zimbra ose MTA krijon skedarë të rinj gjatë dërgimit të mesazhit, bëhet e nevojshme të shkruani në disk ndryshimet që ndodhin në dosjet përkatëse. Kjo është arsyeja pse, edhe nëse skedari tashmë është shkruar në disk duke përdorur fsync, regjistrimi i shtimit të tij në drejtori mund të mos ketë kohë për t'u shkruar në disk dhe, si rezultat, mund të humbasë për shkak të një dështimi të papritur të serverit. Falë përdorimit disinkronizoj këto probleme mund të shmangen.
2. Optimizimi me funksionimin e infrastrukturës Zimbra
Ndodh shpesh që pas disa vitesh përdorimi të Zimbra, numri i përdoruesve të saj rritet ndjeshëm dhe shërbimi bëhet çdo ditë e më pak i përgjegjshëm. Rruga për të dalë nga kjo situatë është e qartë: thjesht duhet të shtoni serverë të rinj në infrastrukturë në mënyrë që shërbimi të funksionojë përsëri aq shpejt sa më parë. Ndërkohë, nuk është gjithmonë e mundur që të shtohen menjëherë serverë të rinj në infrastrukturë për të rritur performancën e saj. Menaxherët e IT-së shpesh duhet të kalojnë një kohë të gjatë duke koordinuar blerjen e serverëve të rinj me departamentin e kontabilitetit ose të sigurisë; përveç kësaj, ata shpesh zhgënjehen nga furnitorët që mund të dorëzojnë një server të ri me vonesë ose madje të dorëzojnë gjënë e gabuar.
Sigurisht, është më mirë të ndërtoni infrastrukturën tuaj Zimbra me një rezervë në mënyrë që të keni gjithmonë një rezervë për zgjerimin e saj dhe të mos vareni nga askush, megjithatë, nëse një gabim tashmë është bërë, menaxheri i IT mund të zbusë pasojat e tij si sa më shumë që të jetë e mundur. Për shembull, një menaxher IT mund të arrijë një rritje të vogël të produktivitetit duke çaktivizuar përkohësisht shërbimet e sistemit Linux që rregullisht aksesojnë hard disqet gjatë funksionimit dhe për këtë arsye mund të ndikojnë negativisht në performancën e Zimbra. Pra, mund të çaktivizoni përkohësisht:
autofs, netfs - Shërbimet e zbulimit të sistemit të skedarëve në distancë
gota — Shërbimi i printimit
xinetd, vsftpd - Shërbimet e integruara *NIX që ndoshta nuk do t'ju nevojiten
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Shërbimet e thirrjes së procedurës në distancë, të cilat zakonisht përdoren në lidhje me sistemet e skedarëve të rrjetit
pëllumbi, cyrus-imapd, sendmail, exim, postfix, ldap — Dublikata të shërbimeve kryesore të përfshira në paketën e bashkëpunimit Zimbra
slocate/updatedb - Meqenëse Zimbra ruan çdo mesazh në një skedar të veçantë, ekzekutimi i shërbimit updatedb çdo ditë mund të shkaktojë probleme, kështu që mund ta bëni manualisht kur serverët janë më pak të zënë.
Kursimi i burimeve të sistemit 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 forcës madhore. Pasi serveri i ri të shtohet në infrastrukturën Zimbra, rekomandohet të riaktivizoni shërbimet e çaktivizuara më parë.
Ju gjithashtu mund të optimizoni funksionimin e Zimbra duke lëvizur shërbimin syslog në një server të veçantë në mënyrë që gjatë funksionimit të mos ngarkojë disqet e ngurtë të ruajtjes së postës. Pothuajse çdo kompjuter është i përshtatshëm për këto qëllime, madje edhe një Raspberry Pi i lirë me një tabelë.
Burimi: www.habr.com