Yn ien fan ús , wijd oan ynfrastruktuerplanning by it ymplementearjen fan Zimbra Collabortion Suite yn in ûndernimming, waard sein dat de wichtichste beheining yn 'e wurking fan dizze oplossing de I / O-snelheid fan skiifapparaten yn postopslach is. Ja, yn in tiid dat ferskate hûnderten meiwurkers fan in bedriuw tagelyk tagong krije ta deselde e-postopslach, kin de kanaalbreedte foar it skriuwen en lêzen fan ynformaasje fan hurde skiven miskien net genôch wêze foar de responsive wurking fan 'e tsjinst. En as foar lytse ynstallaasjes fan Zimbra dit net in bepaald probleem sil wêze, dan kin yn it gefal fan grutte bedriuwen en SaaS-providers dit alles liede ta unresponsive e-post en, as gefolch, in fermindering fan wurknimmer effisjinsje, lykas in oertrêding fan SLAs. Dêrom, by it ûntwerpen en operearjen fan grutskalige Zimbra-ynstallaasjes, moat spesjaal omtinken jûn wurde oan it optimalisearjen fan de prestaasjes fan hurde skiven yn post opslach. Litte wy nei twa gefallen sjen en besykje út te finen hokker metoaden foar it optimalisearjen fan de lading op skiif opslach kinne wurde tapast yn elk fan harren.
1. Optimalisaasje by it ûntwerpen fan in grutskalige Zimbra-ynstallaasje
Tidens de ûntwerpfaze fan in hege-load Zimbra-ynstallaasje sil de behearder in kar meitsje moatte oer hokker opslachsysteem te brûken. Om te besluten oer dit probleem, moatte jo witte dat de wichtichste lading op hurde skiven komt fan 'e MariaDB DBMS opnommen yn' e Zimbra Collaboration Suite, de Apache Lucene sykmasine, en blob opslach. Dêrom is it nedich om hege snelheid en betroubere apparatuer te brûken om dizze softwareprodukten te betsjinjen ûnder betingsten mei hege lading.
Under normale omstannichheden kin Zimbra wurde ynstalleare sawol op RAID fan hurde skiven as op opslach ferbûn fia it NFS-protokol. Foar heul lytse ynstallaasjes kinne jo Zimbra ynstallearje op in gewoane SATA-drive. Yn 'e kontekst fan grutte ynstallaasjes litte al dizze technologyen lykwols ferskate neidielen sjen yn' e foarm fan fermindere opnamesnelheid of lege betrouberens, wat net akseptabel is foar grutte bedriuwen noch, benammen foar SaaS-providers.
Dêrom is it yn grutskalige Zimbra-ynfrastruktuer it bêste om in SAN te brûken. It is dizze technology dy't op it stuit by steat is om de grutste trochstreaming foar opslachapparaten te leverjen en tagelyk, troch de mooglikheid om in grutte hoemannichte cache te ferbinen, it gebrûk praktysk gjin signifikante risiko's foar it bedriuw foarmet. It is in goed idee om NVRAM te brûken, dat wurdt brûkt yn in protte SAN's om dingen te fersnellen tidens skriuwen. Mar it is better om caching fan opnommen gegevens op 'e skiven sels út te skeakeljen, om't it kin liede ta unreparabele skea oan' e media en gegevensferlies as der stroomproblemen foarkomme.
As foar it kiezen fan in bestânsysteem, soe de bêste kar wêze om de standert Linux Ext3 / Ext4 te brûken. De wichtichste nuânse ferbûn mei it triemsysteem is dat it moat wurde monteard mei de parameter -noatime. Dizze opsje sil de funksje fan it opnimmen fan 'e tiid fan' e lêste tagong ta bestannen útskeakelje, wat betsjut dat it de lêst op lêzen en skriuwen sterk sil ferminderje. Yn it algemien, as jo in ext3- of ext4-bestânsysteem meitsje foar Zimbra, moatte jo de folgjende nutparameters brûke mke2fs:
-j - Om in bestânsysteemsjoernaal te meitsjen Meitsje it bestânsysteem mei in ext3/ext4-sjoernaal.
-L NAMME - Om in folume namme te meitsjen om dan te brûken yn /etc/fstab
-O dir_index - Om in hashed sykbeam te brûken om bestânsykjen yn grutte mappen te rapperjen
-m 2 - Om 2% fan it folume te reservearjen yn grutte bestânssystemen foar de rootmap
-J grutte = 400 - Om in grut tydskrift te meitsjen
-b 4096 - Om de blokgrutte yn bytes te bepalen
-ik 10240 - Foar berjochtopslach moat dizze ynstelling oerienkomme mei de gemiddelde berjochtgrutte. Jo moatte betelje omtinken oan dizze parameter, as syn wearde kin net feroare wurde letter.
It is ek oan te rieden om te aktivearjen dirsync foar blob opslach, Lucene sykje metadata opslach, en MTA wachtrige opslach. Dit moat dien wurde om't Zimbra normaal it nut brûkt fsync foar garandearre skriuwen fan in blob mei gegevens op skiif. As de Zimbra-postwinkel of MTA lykwols nije bestannen oanmakket by it leverjen fan berjochten, wurdt it nedich om de wizigingen dy't foarkomme yn 'e oerienkommende mappen op skiif te skriuwen. Dat is wêrom, sels yn it gefal as de triem is al skreaun op skiif mei help fsync, it rekord fan syn tafoeging oan 'e map kin gjin tiid hawwe om nei de skiif te skriuwen en kin as gefolch ferlern gean troch in hommelse serverfout. Mei tank oan it gebrûk dirsync dizze problemen kinne wurde foarkommen.
2. Optimalisaasje mei Zimbra ynfrastruktuer running
It bart faak dat nei ferskate jierren fan it brûken fan Zimbra it oantal brûkers signifikant tanimt en de tsjinst wurdt alle dagen minder en minder responsyf. De wei út dizze situaasje is fanselssprekkend: jo moatte gewoan nije servers tafoegje oan 'e ynfrastruktuer sadat de tsjinst wer sa fluch wurket as earder. Underwilens is it net altyd mooglik om nije servers daliks ta te foegjen oan 'e ynfrastruktuer om de prestaasjes te ferheegjen. IT-managers moatte faaks in lange tiid besteegje oan it koördinearjen fan de oankeap fan nije servers mei de ôfdieling boekhâlding of feiligens; boppedat wurde se faak yn 'e steek brocht troch leveransiers dy't in nije server te let kinne leverje of sels it ferkearde ding leverje.
Fansels is it it bêste om jo Zimbra-ynfrastruktuer te bouwen mei in reserve om altyd in reserve te hawwen foar har útwreiding en net fan ien te ôfhinklik wêze, lykwols, as in flater al makke is, kin de IT-manager allinich de konsekwinsjes útwreidzje as safolle mooglik. Bygelyks, in IT-manager kin in lytse produktiviteitsympuls berikke troch Linux-systeemtsjinsten tydlik út te skeakeljen dy't regelmjittich tagong krije ta hurde skiven tidens operaasje en kinne dêrom de prestaasjes fan Zimbra negatyf beynfloedzje. Dat, jo kinne tydlik útskeakelje:
autofs, netfs - Tsjinsten foar ûntdekking fan bestânsysteem op ôfstân
cups - Printtsjinst
xinetd, vsftpd - Ynboude * NIX-tsjinsten dy't jo wierskynlik net nedich binne
portmap, rpcsvcgssd, rpcgssd, rpcidmapd - Oproptsjinsten op ôfstân, dy't normaal wurde brûkt yn kombinaasje mei netwurkbestânsystemen
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap - Duplikaten fan 'e wichtichste nutsbedriuwen opnommen yn' e Zimbra Collaboration Suite
slocate / updatedb - Om't Zimbra elk berjocht yn in apart bestân opslacht, kin it elke dei de updatedb-tsjinst útfiere problemen feroarsaakje, en dêrom is it mooglik om dit mei de hân te dwaan by de minste lading op 'e servers
It bewarjen fan systeemboarnen as gefolch fan it útskeakeljen fan dizze tsjinsten sil net heul wichtich wêze, mar sels dit kin heul nuttich wêze yn omstannichheden tichtby oermacht. Sadree't de nije tsjinner is tafoege oan de Zimbra-ynfrastruktuer, wurdt it oanrikkemandearre om de earder útskeakele tsjinsten opnij yn te skeakeljen.
Jo kinne ek de wurking fan Zimbra optimalisearje troch de syslog-tsjinst nei in aparte server te ferpleatsen, sadat it tidens operaasje de hurde skiven fan e-postopslach net lade. Hast elke kompjûter is geskikt foar dizze doelen, sels in goedkeape Raspberry Pi mei ien board.
Boarne: www.habr.com